Micah Dowty wrote:
>
> On Mon, 26 March 2001, Pascal Bauermeister wrote:
>
> > ...
> > Concerning native format for image loading, I had a
> > discussion with our Gnome guru, Fred. I'll come back to
> > this topic ASAP, but it seems we can postpone this point.
>
> I have been considering a few options for this.. It seems the
> Gnome project uses mostly XPM and PNG? XPM seems flexible,
> but a bit wasteful in an embedded system context. PNG is
> nice, but probably too slow to decompress?
> I know the BMP format fits the specs nicely: supports a
> palette, supports RLE compression. We could also just make a
> new format, but it would be nice to have something the Gimp
> will export to :)
Completely agree on each point. Therefore I was thinking of a format
containing, in the body, the raw memory area for a couple of
well-chosen depths. If the system is currently in one of these, it
would load the bitmap with no conversion; otherwise it would make a
conversion as usual. This format would not only be uncompressed, but
also a bit wasteful since multiple instances of the bitmap are
contained. Really too big for large bitmaps and probably ok for small
ones (like icons), but in this case conversion/decompression is more
acceptable.
Here we are really in a similar situation as with personal computers
of the early 90' (Amiga, Atari, AppleII, you name it) : few mips,
little memory; and always this big dilemma:
no compression -> loads fasts but mem hungry
compression -> the reverse !
Well, we need first a bit more practical experience (a couple of
weeks) on our ChipSlice, and we'll be able to say where to optimize.
> > Fred is also our autoguru (i.e. autoconf and automake), and
> > he said this project is a typical case where these tools
> > are very well appropriate. Among other good things, this
> > an allow to compile for multiple plateforms/configs by
> > changing .config, but without recompiling everything after
> > a config swap. I'd like to let him setup the
> > auto{conf|make} environment and commit when done. Micah,
> > what do you think about this and giving him a developer
> > access ? his login is "gobry"
>
> Done.
Thanks.
> As long as PicoGUI is still very configurable at
> compile-time, I'd be glad to have a better build system!
No complains about the build system. But auto* allows easy
multi-platform builds, doing all this lot of painful checks you might
have seen while running 'configure' for some projects. It does also
generate dependencies for source files, distribution packages, etc.
etc.
> > We did not manage cascading the 90° rotations, i.e. 180°
> > and 270°. A hint ?
>
> Well, this is more of a rumor than an actual feature... (I
> think brandon misinterpreted me :)
> Main reason this isn't possible is that the video library
> only supports one video wrapper at a time. Besides, this
> cascading would make a lot of confusion between
> logical/physical coordinates. I just need to make video
> wrappers for other angles. This should be pretty simple.
Alright. That was just curiosity. We are currently perfectly happy
with the rotation capabilities.
> > Concerning canvas drawing, let me first announce a cool
> > news:
> > ******** WABA port on pgui is ongoing ! *********
> > Olivier Bornet, our Waba guru (and SF admin) has started
> > porting waba.ui/waba.fx using the canvas widget. He's
> > practically done, but he'd like one option for the canvas:
> > just being a simple pixmap, w/o grops. I don'k now what you
> > Micah recommend: an option for canvas, or a brand new
> > widget, say 'pixmap' ?
>
> How about a command for the canvas that renders a node
> immediately without storing it, like (IIRC) X usually does.
> I suppose you would still need a way to save what's onscreen,
> so it would be nice if it could automatically take a bitmap
> snapshot of the canvas before moving it...
>
> I have been planning a pixmap widget, that will let the app
> use shared memory to go fast graphics. Problem with something
> like this is that you can't use the existing set of
> primitives.
>
> Does the Waba VM have a way to ask the app to redraw itself?
> If not, maybe what's necessary is a better interface to the
> existing canvas widget, so it acts like a traditional
> graphics interface with pr
> imitives that render immediately, but it automatically stores
> what's necessary.
Waba can ask apps to redraw themeselves, but it would be most
efficient if the server would buffer the pixmap content in a
pixel-oriented fashion. Alright, if it is too annoying, we can do
without. After all, a redraw is not needed that frequently, right ?
(since we have no overlapping windows other than modal dialogs, and
provided the user is prevented from playing around with app bars)
Well, if an implementation with shmem could be available, why not ? We
need efficiency, since Waba basic ui/fx will render its widgets by
completely itself (berk)
> > This usage via canvas is a first port for the current Waba
> > object model. It's rather a shame with a GUI system such as
> > PGUI, but it will anable compatibility with existing apps.
> > The final goal is to let Waba really use the various
> > widgets and take advantage of layout management, themes,
> > etc.
> >
>
> Yeah.. I'm hoping for a 'compatibility' interface that will
> emulate Waba's class libraries with a canvas widget, but also
> a native PicoGUI interface where it's appropriate.
We'll be working on this (native) ASAP. But there are a lot of
philosopolitical issues on the object model => lot of discussions on
the Waba mailing lists...
Pascal
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
