On Mon, 16 April 2001, Olivier Bornet wrote:
>
> Hi Micah,
>
> thanks for the PGFX library. It work like I was expecting. Now, I need
> some additions :
>
> - clip functions. Can you implement two functions like :
> pgSetClip( gc, x, y, w, h );
> pgClearClip( gc );
> After a call to pgSetClip, all the drawing outside the (x,y,x+w,y+h)
> don't go to the screen. I'm not shure if this is easy or not with the
> PGFX_PERSISTENT mode, but with PGFX_IMMEDIATE I hope this can be done
> easly. ;-)
Right now the renderer clips to the current divnode. (I don't know if you're familiar
with divnodes. They're the fundamental unit of the layout engine, so it basically
clips to the canvas widget)
Shouldn't be too hard to allow the clipnode to be adjusted, as all the clipping code
is already there.
There's always a balance between gropnode size and included features. I think I'll fix
this by lifting the requirement that a gropnode must be self-contained. With the
current renderer there's no real reason for this. That way the server can use a
seperate node to set the clipping, or set the color, and reduce the information
required in each individual node.
>
> - something like gdk_gc_set_function() : "Determines how the current
> pixel values and the pixel values being drawn are combined to produce
> the final pixel values." This mean the following drawing are either
> COPY, OR, AND, XOR, INVERT, etc., with the allready drawed. Something
> like :
> pgSetDrawFunction( gc, flag );
> Where flag can be PG_LGOP_OR, PG_LGOP_AND...
This falls in the same category as rendering to bitmaps, I will need to make changes
to the video library. That's probably what I should start next...
>
> - read of the actual drawed value, both for one pixel and for one
> region. Like :
> pgcolor pgGetPixel( gc, y, x );
> pgcolor **pgGetRegion( gc, x, y, w, h );
ok. It would also be good to have pgSetRegion, if not just for completeness (but once
rendering to bitmaps is done you could use it to load bitmaps manually)
>
> - of course, I also need the same functions with a bitmap instead of a
> canvas widget. ;-)
Yep. On it's way.
>
> Other comments :
>
> - you have define pgSetcolor(), pgMoveto(), pgLineto(), pgTilebitmap().
> I think is better if you put an upcase for the 2nd word like all other
> functions in clieng_c.h. This mean, having for example pgSetColor().
Good idea. I'll fix this next time I have CVS access (stupid firewalls ;-)
>
> - try to use helvetica with PG_FSTYLE_BOLD. Letters are not all on the
> same baseline (y).
This is a bug in the font converter. I should take a look at it.
>
> - I have some problems at start with PGFX_IMMEDIATE, and not with
> PGFX_PERSISTENT (nothing draw in my 1st "paint" function, but after
> all is OK). I will try now to find why, but if only this small
> explanation give you an idea, let me know.
Did you call pgContextUpdate()?
>
> - using pgSetIdle() cause sometime error on the server :
> *** PicoGUI ERROR (HANDLE) : The handle you seek has been found, but
> it is not what you are looking for.
> I suspect this is when I have a too low value for the timeout, but
> this is strange. This is also a point I will look, but if you have an
> idea...
I've seen this before in omnibar. It's a race condition, but I'm not sure where yet.
>
> Thanks for the good job, and have a nice week.
Thanks!
>
> 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
