|Site sponsored by IGEL|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[directfb-dev] Re: gifs and windows
Quoting Sven Neumann (firstname.lastname@example.org): > Hi, > > Till Adam <email@example.com> writes: > > > > If you want to do it, you are of course free to do so. Please notice that > > > we would most likely not include such a loader with DirectFB. Bundling > > > it with DFBSee might make sense however. But IMHO it would make much more > > > sense to do a gdk-pixbuf or an imlib2 image provider. This would enable > > > DFBSee to load a whole bunch of formats without reimplementing the wheel > > > once more. > > > > In principle I couldnt agree more, but what about the additional > > dependencies? Very large parts of Imlib2 a least ( I dont know anything > > about gdk-pixbuf ) would very likely never be used on a framebuffer > > based system. Just a thought. > > I haven't looked into it in detail yet, but I think it should be possible > to implement a DirectFB image provider that uses the loader modules from > gdk-pixbuf without depending or using gdk-pixbuf at all. All we'd have to > do is to mimic the relevant parts of the gdk-pixbuf API to the modules. > We'd not even have to recompile them. The best way is to write ImageProviders that can load one specific format. They should be small and have no more than one or two dependencies to other libs. The Image Provider implementor should concentrate on that format and optimize the Provider for speed and image quality. This way we keep it really modularized and prevent "dependency trees". But I agree that a multifunctional provider could be a "helper" until special image providers are available. -- Denis Oliver Kropp ( convergence ) ( integrated media gmbh ) -- Info: To unsubscribe send a mail to firstname.lastname@example.org with "unsubscribe directfb-dev" as subject.