Ok, i understand what you're asking. The reason why this is difficult now is that the
primitives in the video driver can only render to the screen. Offscreen rendering to a
bitmap is not yet supported.
This could probably be implemented by adding an extra 'destination' pointer to all
primitives. Then it would be possible to have something closer to the traditional
'device context' way of rendering.
On Tue, 03 April 2001, Olivier Bornet wrote:
>
> Hi Micah,
>
> On Mon, Mar 26, 2001 at 09:03:03AM -0800, Micah Dowty wrote:
> >
> > On Mon, 26 March 2001, Pascal Bauermeister wrote:
> > > ...
> > > 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...
>
> If I can make something like this, I will be happy :
>
> pgWriteCmd( w, PGCANVAS_MK_BITMAP, 0 );
> pgSubUpdate( w );
>
> The 1st command (PGCANVAS_MK_BITMAP) just change the result of all
> the GROP in the list to a list with only one PG_GROP_BITMAP. This mean
> a PGCANVAS with many GROPS like LINE, RECT, TEXT... can be transformed
> to one GROP of type PG_GROP_BITMAP. (hope this is enough clear ?:-\ )
>
> I think this is the 1st step (and the fastest). I also need to have
> some explanation on how to handle PG_GROP_BITMAP, like the one you
> have made for the PG_GROP_TEXT.
>
> > 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.
>
> Why can we use the existing set of primitives ? Are they not enough
> fast ?
>
> > Does the Waba VM have a way to ask the app to redraw itself?
>
> Yes, the Waba VM have it.
>
> > If not, maybe what's necessary is a better interface to the existing
> > canvas widget, so it acts like a traditional graphics interface with
> > primitives that render immediately, but it automatically stores what's
> > necessary.
>
> For the moment, I think this is not necessary.
>
> > > 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.
>
> The compatibility interface is on the way. And the support of the
> native PicoGUI interface is in the design phase... Stay tuned...
>
> Thanks in advance for the help.
>
> 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
