On Fri, 13 April 2001, Olivier Bornet wrote:
>
> Hi Micah,
>
> > Just to let everyone know where they are in the queue :)
> > Here's my current short-term todo list:
> > 1. Write PGFX
> > 2. Tomorrow (friday) night fix ez328 rotate bug
> > 3. Re-test and fix ncursesinput
> > 4. Make video drivers fast
>
> Looks good for me. And if it's written by priority, very great : the
> PGFX will be available for the 1st test very soon. I'm very happy, and
> impatient to test.
>
> > The PGFX interface functions themselves are nice short primitives,
> > that operate on a pgcontext. The pgcontext contains a table of function
> > pointers that implement the primitives, and it contains information
> > about the rendering device.
>
> The pgcontext structure seems fine for me. I'm just curious of what is
> the device field. Is it just for example the canvas used when we create
> the pgcontext with pgnewCanvasContext ?
Well, the apps probably shouldn't be doing anything to the pgcontext anyway because
it's implementation dependant. But, yes, the device field can be a canvas widget. If
the context is outputting to a bitmap, it might be a bitmap handle.
>
> > The app will obtain a pgcontext using a rendering-device-specific
> > function, then render to it without regard to what it actually is (well,
> > mostly). I have started a pgfx backend for the canvas widget. There will
> > be an 'immediate' mode and a 'persistent' mode. The immediate mode will
> > implement a more traditional drawing model where each group of
> > primitives is packaged, sent to the server, and rendered, but not
> > stored. The persistent mode would expose more of PicoGUI's gropnode
> > manipulation functionality and allow the server to do more work for the
> > client, at the cost of some complexity in the client.
>
> Great ! The immediate mode is just what I need now for using PicoGUI
> with the current Waba implementation.
>
> > When the bitmap-based primitives in pgserver are available, a pgfx
> > backend will be written for them allowing the app to easily switch
> > rendering methods. (enable/disable double-buffer for example)
>
> Seem also OK. I think I can use this for loading bitmap file (.bmp
> Window$ files) when this will be available.
Well, not really. This will let apps write into bitmaps but it's not really intended
for loading purposes. That should be done in the server.
I was planning on implementing a BMP loader in the server soon, when do you need this?
>
> > I would suggest anyone interested in the client-side graphics
> > operations take a glance through pgfx.h and make sure it's reasonable,
> > because that's the API you'll be using :)
>
> The API looks good for me. Thanks a lot.
>
> Thanks for this good jobs, and have a nice day.
Happy Friday!
:^D
>
> Olivier
> --
> Olivier Bornet SMARTDATA SA
> [EMAIL PROTECTED] Centre du Parc
> http://www.smartdata.ch av. des Pr�s-Beudin 20
> Phone +41-27-723'55'03 1920 Martigny
> Fax +41-27-723'55'19 Phone +41-27-723'55'18
>
> _______________________________________________
> Pgui-devel mailing list
> [EMAIL PROTECTED]
> http://lists.sourceforge.net/lists/listinfo/pgui-devel
--
perl -e'socket S,2,1,tcp;connect S,pack(H16,"0200029a80692d32").\0x8;print
grep!/=/,<S>'
_______________________________________________
Pgui-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/pgui-devel
