[Development] Texture image loading library

Sean Harmer sean.harmer at kdab.com
Sat Jan 21 14:25:41 CET 2017


On Saturday 21 January 2017 13:51:15 André Pönitz wrote:
> On Sat, Jan 21, 2017 at 10:51:11AM +0000, Sean Harmer wrote:
> > On Friday 20 January 2017 20:35:49 Konstantin Tokarev wrote:
> > > 20.01.2017, 00:22, "Oswald Buddenhagen" <oswald.buddenhagen at qt.io>:
> > > > On Thu, Jan 19, 2017 at 07:34:08PM +0100, Giuseppe D'Angelo wrote:
> > > >>  Nonetheless, since such loaders would be useful in more than one
> > > >>  place
> > > >>  (qtbase, qtdeclarative, qt3d) I think that the best place for them
> > > >>  would
> > > >>  be a new private library in qtimageformats.
> > > > 
> > > > you can't put it there if qtbase is to use it.
> > > > 
> > > > the central "regular" image loaders are in qtgui, and the "elementary"
> > > > (6MeB of sources ...) opengl support is nowadays also in qtgui, so it
> > > > seems quite plausible to put the texture loaders there as well.
> > > 
> > > FWIW not everyone is happy by fact that QtGui is bloated with OpenGL
> > > code
> > > and pulls in OpenGL libraries into application adress space with itself.
> > 
> > Well that decision was made prior to Qt 5.0 being released.
> 
> I think it's about time to stop using the existence of decisions that were
> made around the 5.0 release as part of a technical discussion.

I'm not. I'm pointing out that this technical decision has nothing to do with 
the one to put OpenGL dependent related features in QtGui.

> 2012 was a very special year for Qt development, in a very special
> environment, leading to very special decisions, some of which already at
> that time were made knowing that they are only acceptable in this context.

Well, some of us don't have visibility of what decisions were made, the 
reasoning behind them and what issues were identified, as that took place 
behind closed doors.

> Yes, there might still be real consequences for Qt development today, e.g.
> due to the independently existing compatibility promises, which, might
> make it impossible to disentangle Qt Gui and OpenGL, leading to the same
> conclusion. But then *this* argument should be used.

For the record I have no problem with removing the OpenGL dependency from 
QtGui in the future. It's possible now to compile with it stripped out but of 
course that's an all or nothing approach. I don't see how we could rectify 
this in the Qt5 life time. Anyway, that's not what this thread is about. It's 
about being able to parse texture files into CPU addressable memory. From there 
it can be used by OpenGL, Direct3D, Vulkan, Metal, $OTHER_API.

Sean
--
Dr Sean Harmer | sean.harmer at kdab.com | Managing Director UK
Klarälvdalens Datakonsult AB, a KDAB Group company
Tel. UK +44 (0)1625 809908, Sweden (HQ) +46-563-540090
KDAB - Qt Experts - Platform-independent software solutions



More information about the Development mailing list