|
Prima::gp-problems - Problems, questionable or intricate topics in 2-D Graphics |
Prima::gp-problems - Problems, questionable or intricate topics in 2-D Graphics
One of the most important goals of the Prima project is portability between different operating systems. Independently to efforts in keeping Prima internal code that it behaves more or less identically on different platforms, it is always possible to write non-portable and platform-dependent code. Here are some guidelines and suggestions for 2-D graphics programming.
A compliant display is expected to have minimal set of capabilities, that programmer can rely upon. Following items are guaranteedly supported by Prima:
Line widths 0 and 1
One monospaced font
Solid fill
rop::Copy and rop::NoOper
Line,PolyLine,PolyLines
Ellipse,Arc,Chord,Sector
Rectangle
FillPoly
FillEllipse,FillChord,FillSector
TextOut
PutImage,GetImage
GetImageBitsLayout
backColor
rop
backRop
lineWidth
lineJoin
lineStyle
fillPattern
fillPolyWinding
textOpaque
clipRect
All these properties must be present, however it is not required for them to be changeable. Even if an underlying platform-specific code can only support one mode for a property, it have to follow all obligations for the mode. For example, if platform supports full functionality for black color but limited functionality for the other colors, the wrapping code should not allow color property to be writable then.
Example: if white color on 8-bit display occupies palette index 15 then desired masking effect wouldn't work for xoring transparent areas with cl::White.
Workaround: Use two special color constants cl::Clear and cl::Set, that represent all zeros and all ones values for bit-sensitive raster operations.
11111000 11111000 11111000 --R----- --G----- --B-----
that equals to 0xf8f8f8. (All)
Advise: do not check for 'blackness' and 'whiteness' merely by comparing a pixel value.
It is not checked how does Prima behave when a pixel value and a platform integer use different bit and/or byte priority (X).
NB - has nothing in common with the fill winding rule.
Workaround: Do not use raster operations with complex filled shapes
Workaround: Do not use patterned backgrounds. Since the same effect is visible on dithered backgrounds, routine check for pure color might be applied.
Workaround: use predefined patterns (lp::XXX)
Impact: system-dependent font description may not match to Prima's.
Advise: do not try to deduce Prima font metrics from system-dependent ones and vice versa.
Impact: font emulation is laborsome, primarily because the glyphs have to be plotted by consequential anding and xoring a bitmap. Full spectrum of the raster operations cannot be achieved with this approach.
Example: A set of glyphs has width of 8.6 pixels for each symbol. If the string ``abcd'' is drawn at position 0, then black part of ``d'' starts at 25th pixel, but if ``cd'' is drawn at 17th, as it supposed to be if the integer arithmetics is used, it starts at 24th pixel. (OS/2)
Solution: Do not rely to Drawable::get_text_width information, because it always returns integer value, but to Drawable::get_font_abc, which returns real values.
Text background may be only drawn with pure ( non-dithered ) color (Win9X,WinNT) - but this is (arguably) a more correct behavior.
Advise: Do not use ::rop2 and text background for special effects
Raster fonts cannot be synthesized (OS/2, partly X)
Background raster operations are not supported (X,Win9X,WinNT) and foreground ROPs have limited number of modes (OS/2,X). Not all ROPs can be emulated for certain primitives, like fonts, complex shapes, and patterned shapes.
It is yet unclear which primitives have to support ROPs, - like FloodFill and SetPixel. Behavior of the current implementation is that they do not.
Platforms tend to produce different results for angles outside 0 and 2pi. Although Prima assures that correct plotting would be performed for any angle, minor inconsistencies may be noticed. If emulating, note that 2 and 4-pi arcs are not the same - for example, they look differently with rop::Xor.
Win9X/WinNT - only one top-level window at a time and its direct children ( not ::clipOwner(0)) can benefit from using Widget::palette. System palette is switched every time as different windows moved to the front.
OS/2 - not implemented, but in principle the same as under win32.
X - Any application can easily ruin system color table. Since this behavior is such by design, no workaround can be applied here.
Workaround: none
Some ROPs are ambiguous - SRCTRANSPARENT, for example. Some times they work, some times they don't. The particular behavior depends on a video driver.
Circles cannot be drawn using an even diameter.
Fast GDI operations on HWND_DESKTOP may be delayed, thus GetPixel may return invalid pixel values.
Amount of GDI objects can not exceed some unknown threshold - experiments show that 128 objects is safe enough.
No transformations.
Color cursor creation routine is broken.
Filled shapes are broken.
No transformations
No bitmap scaling
No font rotation
No GetPixel, FloodFill ( along with some other primitives)
White is not 2^n-1 on n-bit paletted displays (tested on XFree86).
Filled shapes are broken.
Color bitmaps cannot be drawn onto mono bitmaps.
Palettes are not implemented
Plotting speed of DeviceBitmaps is somewhat less on 8-bit displays than Images and Icons. It is because DeviceBitmaps are bound to their original palette, so putting a DeviceBitmap onto different palette drawable employs inefficient algorithms in order to provide correct results.
Image that was first drawn on a paletted Drawable always seen in 8 colors if drawn afterwards on a Drawable with the different palette. That is because the image has special cache in display pixel format, but cache refresh on every PutImage call is absolutely inappropriate (although technically possible). It is planned to fix the problem by checking the palette difference for every PutImage invocation. NB - the effect is seen on dynamic color displays only.
Dmitry Karasik, <dmitry@karasik.eu.org>.
Prima
|
Prima::gp-problems - Problems, questionable or intricate topics in 2-D Graphics |