Bug-4-U in GDI+
-
Hi People, The latest bug for your attention is the conversion of GraphicsPath objects into Regions. If you look at the articles on Balloon's (search Balloon on Article Titles) you will notice the outline of the Balloons are generally flawed (pixels missing, uneveness in the arcs). It appears the algorithm used by regions to interpret a path are seriously flawed. I expected the region would either provide an area within the confines of the path, or encompass the path itself. It fact it does neither. On investigation I've found that the conversion from GraphicsPath to Region creates unpredicatable errors both for arcs and even for straight lines! I tried every combination I could think of, and in the end my only advice is to avoid this api completely (ie. Region aRegion = new Region(aPath)) The best workaround, for the Balloon example, is to combine rectangular regions until you have the shape you want (Union, Exclude etc). This works perfectly I am pleased to say, although I have no idea what the real-time penalty might be. In general I find the GDI+ concept to be excellent in many respects, but the absence of XOR functions, the errors in MeasureString(), true transparency and the all-too-frequent 1-2 pixel errors evident in internal calculations, are extremely annoying. Especially since neither of the two SP's address any of these issues. WAKE UP MICROSOFT AND SMELL THE COFFEE. SURELY YOU HAVE ENOUGH COFFEE IN SEATTLE Only change is constant
-
Hi People, The latest bug for your attention is the conversion of GraphicsPath objects into Regions. If you look at the articles on Balloon's (search Balloon on Article Titles) you will notice the outline of the Balloons are generally flawed (pixels missing, uneveness in the arcs). It appears the algorithm used by regions to interpret a path are seriously flawed. I expected the region would either provide an area within the confines of the path, or encompass the path itself. It fact it does neither. On investigation I've found that the conversion from GraphicsPath to Region creates unpredicatable errors both for arcs and even for straight lines! I tried every combination I could think of, and in the end my only advice is to avoid this api completely (ie. Region aRegion = new Region(aPath)) The best workaround, for the Balloon example, is to combine rectangular regions until you have the shape you want (Union, Exclude etc). This works perfectly I am pleased to say, although I have no idea what the real-time penalty might be. In general I find the GDI+ concept to be excellent in many respects, but the absence of XOR functions, the errors in MeasureString(), true transparency and the all-too-frequent 1-2 pixel errors evident in internal calculations, are extremely annoying. Especially since neither of the two SP's address any of these issues. WAKE UP MICROSOFT AND SMELL THE COFFEE. SURELY YOU HAVE ENOUGH COFFEE IN SEATTLE Only change is constant
maybe this is related to the topic of the current survey...
A man is like a rusty wheel on a rusty cart, He sings his song as he rattles along and then he falls apart. -- Richard Thompson
-
maybe this is related to the topic of the current survey...
A man is like a rusty wheel on a rusty cart, He sings his song as he rattles along and then he falls apart. -- Richard Thompson
What survery are you talking about? I seem to have missed this. I don't understand what has gotten into microsoft. I've used Studio since its inception, and I've never seen anything like this. Commands as basic as converting a path into a region, measuring a string, performing floating point conversions, updating database, drawing symetric arcs... you would think that at least the minimum functionality would've been tested! I still like .NET for all the principles it embodies, and I far prefer C# over C++, Visual Basic or Java. But it is very exasperating having to go around so many key flaws. However, I soldier on. Only change is constant
-
What survery are you talking about? I seem to have missed this. I don't understand what has gotten into microsoft. I've used Studio since its inception, and I've never seen anything like this. Commands as basic as converting a path into a region, measuring a string, performing floating point conversions, updating database, drawing symetric arcs... you would think that at least the minimum functionality would've been tested! I still like .NET for all the principles it embodies, and I far prefer C# over C++, Visual Basic or Java. But it is very exasperating having to go around so many key flaws. However, I soldier on. Only change is constant
Alastair Stell wrote: What survery are you talking about? CP front page, weekly survey. Alastair Stell wrote: However, I soldier on. faith be with you, good sir. -c
A man is like a rusty wheel on a rusty cart, He sings his song as he rattles along and then he falls apart. -- Richard Thompson
-
Hi People, The latest bug for your attention is the conversion of GraphicsPath objects into Regions. If you look at the articles on Balloon's (search Balloon on Article Titles) you will notice the outline of the Balloons are generally flawed (pixels missing, uneveness in the arcs). It appears the algorithm used by regions to interpret a path are seriously flawed. I expected the region would either provide an area within the confines of the path, or encompass the path itself. It fact it does neither. On investigation I've found that the conversion from GraphicsPath to Region creates unpredicatable errors both for arcs and even for straight lines! I tried every combination I could think of, and in the end my only advice is to avoid this api completely (ie. Region aRegion = new Region(aPath)) The best workaround, for the Balloon example, is to combine rectangular regions until you have the shape you want (Union, Exclude etc). This works perfectly I am pleased to say, although I have no idea what the real-time penalty might be. In general I find the GDI+ concept to be excellent in many respects, but the absence of XOR functions, the errors in MeasureString(), true transparency and the all-too-frequent 1-2 pixel errors evident in internal calculations, are extremely annoying. Especially since neither of the two SP's address any of these issues. WAKE UP MICROSOFT AND SMELL THE COFFEE. SURELY YOU HAVE ENOUGH COFFEE IN SEATTLE Only change is constant
Alastair Stell wrote: the absence of XOR functions I believe the official stance on this is that XOR drawing was a hack that doesn't need to be used anymore. I've heard rumors that GDI+ will soon/eventually use DirectX to provide accelerated drawing so it truly won't be needed anymore. The problem with XOR is that you can't control the color that is output from using it so the result can be less than spectacular, especially if you XOR on a background in the range of RGB(128, 128, 128) [maybe it was some other gray color]. Alastair Stell wrote: Especially since neither of the two SP's address any of these issues. You're confusing GDI+ for .NET here; to my knowledge there have been no SPs released for GDI+, but since the System.Drawing classes wrap the GDI+ classes I can see why you would get confused here. There has been at least one QFE[^] released which fixed some problems. Alastair Stell wrote: SURELY YOU HAVE ENOUGH COFFEE IN SEATTLE *cough* Redmond *cough* ;) James "And we are all men; apart from the females." - Colin Davies
-
Alastair Stell wrote: the absence of XOR functions I believe the official stance on this is that XOR drawing was a hack that doesn't need to be used anymore. I've heard rumors that GDI+ will soon/eventually use DirectX to provide accelerated drawing so it truly won't be needed anymore. The problem with XOR is that you can't control the color that is output from using it so the result can be less than spectacular, especially if you XOR on a background in the range of RGB(128, 128, 128) [maybe it was some other gray color]. Alastair Stell wrote: Especially since neither of the two SP's address any of these issues. You're confusing GDI+ for .NET here; to my knowledge there have been no SPs released for GDI+, but since the System.Drawing classes wrap the GDI+ classes I can see why you would get confused here. There has been at least one QFE[^] released which fixed some problems. Alastair Stell wrote: SURELY YOU HAVE ENOUGH COFFEE IN SEATTLE *cough* Redmond *cough* ;) James "And we are all men; apart from the females." - Colin Davies
XOR is useful for small scale animation and effects. I don't see your argument on RGB follows at all, but maybe you have a different use in mind. I also don't see that GDI+ offers a particularly appetizing alternative. The consequence is either to drop down to GDI (BitBltn etc) or put up with annoying flicker. XOR is built into the i86 language from day one, so it is hardly a patch to make use of it. I thought the essence of GDI+ was to make graphics simpler, more accessible, portable and consistent. A GDI+ style wrap for DirectX might be interesting, especially in regard to portability, but Microsoft should concentrate on making the existing product work before embarking on this feature. Your comment regarding Service Packs is intersting. Now that applications are built with Studio for a .NET framework, it is harder to know where the problem lies. But should I really care or distinguish? My job is to design product and cut code, not scour Microsoft's web pages for obscure patches. Incidentally the QFE you linked to was a rendering problem specifically for XP, and I have verified the same faults exist on all platforms. What Microsoft needs is a developer's page where we can report errors, have a tracking number assigned for all to see, and some progress indicator towards fixing the bug (and the SP in which the fix can be found). It's that simple. Maybe the boys in Seattle should send some coffee down to Redmond. Whoever makes the delivery should also administer a pointy boot to wake them up. But thank you for your comments. Now if only you worked for microsoft, we might achieve something! Only change is constant