Hi,
Till Adam <[EMAIL PROTECTED]> 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.
IMHO DirectFB itself does not need more image providers. For DFBSee and
similar programs it makes sense to have more of them available, but for
embedded systems and games what we have now should be sufficient. I even
question the general usefulness of the GIF loader. Our goal should thus
be to make it possible to easily compile third-party DirectFB interfaces
outside the DirectFB source tree. This is on our list of things to do,
but it's not top priority.
Salut, Sven
--
Info: To unsubscribe send a mail to [EMAIL PROTECTED] with
"unsubscribe directfb-dev" as subject.
