1pod::Prima::gp-problemsU(s3e)r Contributed Perl Documentaptoido:n:Prima::gp-problems(3)
2
3
4

NAME

6       Prima::gp-problems - Problems, questionable or intricate topics in 2-D
7       Graphics
8

Introduction

10       One of the most important goals of the Prima project is portability
11       between different operating systems. Independently to efforts in
12       keeping Prima internal code that it behaves more or less identically on
13       different platforms, it is always possible to write non-portable and
14       platform-dependent code.  Here are some guidelines and suggestions for
15       2-D graphics programming.
16

Minimal display capabilities

18       A compliant display is expected to have minimal set of capabilities,
19       that programmer can rely upon.  Following items are guaranteedly
20       supported by Prima:
21
22       Minimal capabilities
23           Distinct black and white colors
24
25           Line widths 0 and 1
26
27           One monospaced font
28
29           Solid fill
30
31           rop::Copy and rop::NoOper
32
33       Plotting primitives
34           SetPixel,GetPixel
35
36           Line,PolyLine,PolyLines
37
38           Ellipse,Arc,Chord,Sector
39
40           Rectangle
41
42           FillPoly
43
44           FillEllipse,FillChord,FillSector
45
46           TextOut
47
48           PutImage,GetImage
49
50       Information services
51           GetTextWidth,GetFontMetrics,GetCharacterABCWidths
52
53           GetImageBitsLayout
54
55       Properties
56           color
57
58           backColor
59
60           rop
61
62           backRop
63
64           lineWidth
65
66           lineJoin
67
68           lineStyle
69
70           fillPattern
71
72           fillPolyWinding
73
74           textOpaque
75
76           clipRect
77
78           All these properties must be present, however it is not required
79           for them to be changeable. Even if an underlying platform-specific
80           code can only support one mode for a property, it have to follow
81           all obligations for the mode. For example, if platform supports
82           full functionality for black color but limited functionality for
83           the other colors, the wrapping code should not allow color property
84           to be writable then.
85

Inevident issues

87   Colors
88       Black and white colors on paletted displays
89           Due the fact that paletted displays employ indexed color
90           representation, 'black' and 'white' indices are not always 0 and
91           2^n-1, so result of raster image operations may look garbled (X).
92           Win32 protects themselves from this condition by forcing white to
93           be the last color in the system palette.
94
95           Example: if white color on 8-bit display occupies palette index 15
96           then desired masking effect wouldn't work for xoring transparent
97           areas with cl::White.
98
99           Workaround: Use two special color constants cl::Clear and cl::Set,
100           that represent all zeros and all ones values for bit-sensitive
101           raster operations.
102
103       Black might be not 0, and white not 0xffffff
104           This inevident issue happens mostly on 15- and 16-bits pixel
105           displays. Internal color representation for the white color on a
106           15-color display ( assuming R,G and B are 5-bits fields) is
107
108            11111000 11111000 11111000
109            --R----- --G----- --B-----
110
111           that equals to 0xf8f8f8. (All)
112
113           Advise: do not check for 'blackness' and 'whiteness' merely by
114           comparing a pixel value.
115
116       Pixel value coding
117           Status: internal
118
119           It is not checked how does Prima behave when a pixel value and a
120           platform integer use different bit and/or byte priority (X).
121
122   Filled shapes
123       Dithering
124           If a non-solid pattern is selected and a background and/or a
125           foreground color cannot be drawn as a solid, the correct rendering
126           requires correspondingly 3 or 4 colors.  Some rendering engines
127           (Win9X) fail to produce correct results.
128
129       Pattern offset
130           For a widget that contains a pattern-filled shape, its picture will
131           be always garbled after scrolling, because it is impossible to
132           provide an algorithm for a correct rendering without a prior
133           knowledge of the widget nature. (All)
134
135           Workaround: Do not use patterned backgrounds.  Since the same
136           effect is visible on dithered backgrounds, routine check for pure
137           color might be applied.
138
139   Lines
140       Line caps over patterned styles
141           It is not clear, whether gaps between dashes should be a multiple
142           to a line width or not. For example, lp::DotDot looks almost as a
143           solid line when lineWidth is over 10 if the first (non-multiple)
144           tactic is chosen.  From the other hand it is hardly possible to
145           predict the plotting strategy from a high-level code. The problem
146           is related more to Prima design rather than to a platform-specific
147           code. (All)
148
149           Workaround: use predefined patterns (lp::XXX)
150
151       Dithering
152           Dithering might be not used for line plotting. (Win9X)
153
154       Arcs and circles
155           Drawing is dependent in X11 on an X servers - different X servers
156           do different plotting strategies on small (less than 3 pixels)
157           diameters. Current version is adapted best to the latest (2010)
158           Xorg capabilities. See discussion on CPAN bug
159           https://rt.cpan.org/Ticket/Display.html?id=62972 .
160
161   Fonts
162       Font metric inconsistency
163           A font is loaded by request with one size, but claims another
164           afterwards.(X).
165
166           Impact: system-dependent font description may not match to Prima's.
167
168           Advise: do not try to deduce Prima font metrics from system-
169           dependent ones and vice versa.
170
171       Transparent plotting
172           No internal function for drawing transparent bitmaps (like fonts).
173           Therefore, if a font emulation is desired, special ROPs cannot be
174           reproduced. (Win9X, WinNT)
175
176           Impact: font emulation is laborsome, primarily because the glyphs
177           have to be plotted by consequential anding and xoring a bitmap.
178           Full spectrum of the raster operations cannot be achieved with this
179           approach.
180
181       Kerning
182           Prima do not use text kernings, nor encourages underlying platform-
183           specific code to use it - primarily because of its complexity.
184           From the other hand, sometimes glyph position cannot be determined
185           correctly if no information for the text kerning is provided.
186           (Win9X)
187
188       Text background
189           If a text is drawn with non-CopyPut raster operation, text
190           background is not expected to be mixed with symbols - however this
191           is hardly reachable, so results differs for different platforms.
192
193           Text background may be only drawn with pure ( non-dithered ) color
194           (Win9X,WinNT) - but this is (arguably) a more correct behavior.
195
196           Advise: Do not use ::rop2 and text background for special effects
197
198       Internal platform features
199           Font change notification is not provided. (X)
200
201           Raster fonts cannot be synthesized (partly X)
202
203   Raster operations ( ROPs)
204       Background raster operations are not supported (X,Win9X,WinNT) and
205       foreground ROPs have limited number of modes (X). Not all ROPs can be
206       emulated for certain primitives, like fonts, complex shapes, and
207       patterned shapes.
208
209       It is yet unclear which primitives have to support ROPs, - like
210       FloodFill and SetPixel. Behavior of the current implementation is that
211       they do not.
212
213       On win32, BlendAlpha call is used to implement ropSrcOver function on
214       32-bit ARGB drawables. It yields results different to the ones yielded
215       by X11/Xrender, that implements the canonic formula by Porter and Duff.
216
217   Arcs
218       Platforms tend to produce different results for angles outside 0 and
219       2pi. Although Prima assures that correct plotting would be performed
220       for any angle, minor inconsistencies may be noticed.  If emulating,
221       note that 2 and 4-pi arcs are not the same - for example, they look
222       differently with rop::Xor.
223
224   Palettes
225       Static palettes
226           Some displays are unable to change their hardware palette, so
227           detecting 8- or 4- bits display doesn't automatically mean that
228           palette is writable.(X)
229
230       Widget::palette
231           Widget::palette property is used for explicit declaration of extra
232           color needs for a widget. The request might be satisfacted in
233           different ways, or might not at all. It is advisable not to rely
234           onto platform behavior for the palette operations.
235
236       Dynamic palette change
237           It is possible (usually on 8-bits displays) for a display to change
238           asynchronously its hardware palette in order to process different
239           color requests. All platforms behave differently.
240
241           Win9X/WinNT - only one top-level window at a time and its direct
242           children ( not ::clipOwner(0)) can benefit from using
243           Widget::palette. System palette is switched every time as different
244           windows moved to the front.
245
246           X - Any application can easily ruin system color table.  Since this
247           behavior is such by design, no workaround can be applied here.
248
249   Bitmaps
250       Invalid scaling
251           Scaling is invalid (Win9X) or not supported (X). Common mistake is
252           to not take into an account the fractional pixels that appear when
253           the scaling factor is more than 1. This mistake can be observed in
254           Win9X.
255
256           Workaround: none
257
258       Large scale factors
259           Request for drawing a bitmap might fail if large scaling factor is
260           selected. (Win9X,WinNT).  This effect is obviously due that fact
261           that these platforms scale the bitmap into a memory before the
262           plotting takes place.
263
264   Layering
265       On win32, layered widgets with pixels assigned zero alpha component,
266       will not receive mouse events.
267

Platform-specific peculiarities

269   Windows 9X
270       Amount of GDI objects can not exceed some unknown threshold -
271       experiments show that 128 objects is safe enough.
272
273       No transformations.
274
275       Color cursor creation routine is broken.
276
277       Filled shapes are broken.
278
279   X
280       No transformations
281
282       No bitmap scaling
283
284       No font rotation
285
286       No GetPixel, FloodFill ( along with some other primitives)
287
288       White is not 2^n-1 on n-bit paletted displays (tested on XFree86).
289
290       Filled shapes are broken.
291
292       Color bitmaps cannot be drawn onto mono bitmaps.
293

Implementation notes

295   Win32
296       Plotting speed of DeviceBitmaps is somewhat less on 8-bit displays than
297       Images and Icons. It is because DeviceBitmaps are bound to their
298       original palette, so putting a DeviceBitmap onto different palette
299       drawable employs inefficient algorithms in order to provide correct
300       results.
301
302   X
303       Image that was first drawn on a paletted Drawable always seen in 8
304       colors if drawn afterwards on a Drawable with the different palette.
305       That is because the image has special cache in display pixel format,
306       but cache refresh on every PutImage call is absolutely inappropriate
307       (although technically possible).  It is planned to fix the problem by
308       checking the palette difference for every PutImage invocation.  NB -
309       the effect is seen on dynamic color displays only.
310

AUTHOR

312       Dmitry Karasik, <dmitry@karasik.eu.org>.
313

SEE ALSO

315       Prima
316
317
318
319perl v5.28.0                      2017-02-27        pod::Prima::gp-problems(3)
Impressum