Home » U++ Library support » Draw, Display, Images, Bitmaps, Icons » BSD problems with Draw
| BSD problems with Draw [message #10094] |
Wed, 20 June 2007 00:22  |
|
|
It looks for me that Cliping with complicated Polygons with holes dosn't work ok on X
1 Screen - some zoom , hard to find which is draw wrong but at leas anything is drawn
2 Scree - 1 zoom moved in such way that hole with circle is Cliped - nothing is drawn
3 - Screen WIN32 everything is ok.
|
|
|
|
|
|
|
|
|
|
| Re: BSD problems with Draw [message #10102 is a reply to message #10094] |
Wed, 20 June 2007 09:48  |
rylek
Messages: 79
Registered: November 2005
|
Member |
|
|
Hello there!
Sorry for that, that's one of 'historical anomalies' which I hope will be resolved soon. It all started with me putting the relatively rich set of polyline / polygon drawing functions into Draw. To make this working under X11, which natively are unable to paint polygons with holes (AFAIK), I incorporated the SplitPolygon routine currently sitting in the Geom package. Mirek didn't like that because at the time he was writing a short application in which the executable size was crucial because it had to fit on a 1.4 MB diskette  and we agreed to drop the SplitPolygon routine and keep only simple polygons working under X (with Mirek's traditional argument that no one but me uses such a silly thing anyway), to which I agreed because WebMap and other of my drawing-intensive applications access the output device via the Tool objects (see Geom/Draw/Plotter.h) where this drawback could be easily fixed.
Now with things like the new image manipulation system or AGG integration under discussion, it might be the right time to either put the SplitPolygon back or, OTOH, to define (with AGG in mind) a generic mechanism for extending the basic Draw interface. This would allow to keep only the basics in the X11 Draw (in this case the simple DrawPolygon method) whereas the more complicated (implementation-wise) functions would be defined e.g. in a hypothetic GeomDraw extension object. However, this brings up the non-trivial question of true portability of Drawings (in the sense of sequences of drawing operations) among various Draws, typically when printing or generating a metafile.
Maybe the right solution would be to have (as Mirek plans it) opaque DrawData blocks in the Drawing stream which only the right Draw extensions would understand; if the target Draw processing the DrawData block didn't understand a block (i.e. if it were a block generated by another Draw extension), it would somehow have to request the registered extension to emulate the block on its output device. More or less, while Windows HDCDraw would understand the DrawPolyPolyPolygon data block and make direct calls to PolyPolygon API to draw it, X11 Draw wouldn't recognize it and force the DrawPolyPolyPolygon registered operation (resp. the registered multipolygon extension) to emulate the complex polygon with basic Draw operations without extensions. Here the extension would naturally perform the SplitPolygon and call DrawPolygon repeatedly to draw the individual parts.
Regards
Tomas
|
|
|
|
| Re: BSD problems with Draw [message #10104 is a reply to message #10099] |
Wed, 20 June 2007 10:35 |
|
|
| luzr wrote on Wed, 20 June 2007 08:00 |
Have you tried the SplitPolygon?
|
I enabled this part of code, no difference.
Look at the picutures, the grey grid lines wich are normaly horizontal and vertical and in this zoom are out of plane are not cliped and are drawn across  .
|
|
|
|
Goto Forum:
Current Time: Tue Apr 16 22:07:09 CEST 2024
Total time taken to generate the page: 0.01405 seconds
|
Members
Pages
Help
Register
Login
Home
