“But it’s full of stars!”

Arthur C. Clarke, 2001: A Space Odyssey

 

This page is rather developer-oriented. Other users should consult the FAQ page to see if their problem was already reported.

This is an overview of problems encountered during EMFexplorer development. For some of them, a workaround is implemented and activated. In some cases the workaround is deactivated, delayed, for further investigation. The remaining cases are opened questions. Most of the time, these questionable parts of the code are put into conditional blocks (#if 1, #if 0).

The source files contain more comments about the issues listed on this page.

Don’t say that a program does not work. Say: “It’s full of stars!”

Table of contents

• ROP
  • Don’t tell me why, just tell me how
• Blitting problems
• Brush problems
• Pen problems
  • ROP2 problems
  • Dash and dots problems
  • Other pen problems
• Font problems
• Missing primitives

ROP

Microsoft has decided to remove ROP (Raster Operation) from GDI (or, more accurately, to NOT USE it in GDI+). Maybe this is good for programmers of that company. But for us this is very bad news. The lack of ROP lead us to acrobatic implementations of functions such as PatBlt or StretchDIBits (with a lot of performance and quality issues).

Don’t tell me why, just tell me how

I have read, here and there, of programmers fulminating about that Microsoft’s decision, and of Micosoft VIPs attempting to convince them that: ROP is not necessary, ROP is not good, ROP wasn’t the fundamental strength of Windows NT, ROP bears device dependency in its heart, etc.

For my part, the question is not whether ROP is technically good or bad. We, programmers, have invested time and money in learning ROP. This reason, alone, is sufficient to keep it if there is no alternative. Indeed, if a company was involved in electronic documents technologies, and was developing a project like EMFexplorer, it would probably go out of business*: as it would be forced to stick with GDI (due to all of the problems linked to ROP listed on that page), and its clients would not understand such a lack of evolution (since there is good in GDI+).

The bottom line is: don’t tell me why, just tell me how; how to ensure that the 16 ROP2 and the 256 ROP3 offered by GDI find their exact equivalent in GDI+.

 

* This is not exaggeration: if this place were appropriate, I would tell the story of one company whose employees went to the soup line when Borland stopped abruptly the evolution of its Pascal compiler to switch to Delphi.

[TOP]

Blitting problems

As a workaround to the lack of ROP in GDI+, functions such as PatBlt, StretchBlt, and StretchDIBits were implemented in EMFexplorer by calls to GDI. Apart the performance issue (as when we access the GDI+ device context, there is a lot of data copy back and forth, according to GDI+ documentation), holes may appear on the output when the bitmaps are placed very closely, as in some gradient patterns.

So there is probably:

• An issue in combination of smoothing modes and pixel offset modes
• A rounding error issue when switching from GDI+ Graphics to GDI HDC
• A rounding error in EMFexplorer itself while computing the blt rectangle

[TOP]

Brush problems

A matrix was unexpectedly discovered in the GDI+ Brush* class. We don’t know what it is doing there. But we are sure it is causing problems: patterns were bigger or smaller than expected.

Note: there is a matrix too in the GDI+ Pen* class; maybe the pen problems are related to it too.

* If the Graphics object that is using a brush has a transform matrix, should the brush passed to it have one too?

[TOP]

Pen problems

ROP2 problems

When SetROP2 is called with an argument other than R2_COPYPEN, EMFexplorer is in trouble.

We have found workaround for ROPs like R2_MASKPEN. The rest is to be investigated.

Dash and dots problems

Dashed and dotted lines appear as solid at some “normal” scales (below 150%). Then, at some larger scale, they begin to look as they should.

 

Maybe the problem is due to smoothing: the small space between the gaps is used by the smooth. But for the end-user, only the final result is important, not the explanation (don’t tell me why, just tell me how). Workaround: we could keep line smoothing only for solid lines, but this would defeat the very purpose of EMFexplorer.

Other pen problems

More investigation is required on:

• Line caps: for lines drawn with a basic pen (LOGPEN, as opposed to EXTLOGPEN);
• Line joins: corners of rectangles.

Some code was written to fix the problem. But as it is not guaranteed to work in all cases, it was deactivated.

[TOP]

Font problems

Sometimes, GDI+ refuses to use a private TrueType font (that was installed by the application); it replies with an enigmatic “NotATrueType”.

Other surprises were texts disappearing if the font style contains Underline or Strikeout attributes.

Missing primitives

Primitives to do the following operations were not found in GDI+1.0:

• Angle arcs
• Chords (no DrawChord, FillChord in the Graphics class)
• Flood Fill
• PolyPolygon
• Round rectangles
• Texts into path with accurate character positioning (the DrawDriverString equivalent)

Workaround was implemented for them. But this is a potential source of problems.

[TOP]