Community
Participate
Working Groups
Build ID: I20081211-1908 SWT's GC boolean "advanced mode" only supports two underlying rendering platforms per platform (of which there will be more with e4) and has implications about method calls that should be made more explicit and flexible. When in one mode or another, certain graphics functions are either natively supported, emulated, or forbidden (throw an exception), but while that mapping between mode and capabilities is only documented, it isn't compiled in. Maybe something like this would be better? if(gc.isSupported(GC.CAP_BACKGROUND_PATTERNS)) { // use a background pattern if we can figure.setBackground(pattern); } else { // but if we can't, use a semitransparent solid color figure.setBackground(blue); figure.setAlpha(200); } // only anti-alias if it won't hurt performance gc.setAntialias(gc.isAccelerated(GC.CAP_ANTI_ALIAS)); It would also provide more flexibility to cover the union of platform capability sets rather than their intersection. For example, letting clients use xor mode if the capability is there and let them pick an alternative method when it's not, instead of just deprecating it.
(In reply to comment #0) > When in one mode or another, certain graphics functions are either natively > supported, emulated, or forbidden (throw an exception), but while that mapping > between mode and capabilities is only documented, it isn't compiled in. You can't have everything in compiled in. IMO, if the doc says certain functions only work in advance mode -and- you have a way to detect if advance mode is available, then I don't think you need an API to test each functionality independently.
I think we WONTFIX this. Platforms that don't support advanced graphics are few and far between these days (Windows 2000, Motif on some Unix workstations). Silenio?
I agree non-advanced graphics has gone the way of the dodo, but I was thinking more towards future uses. For example, to indicate radial gradient support whn running on Flex, a third platform which can't be represented by the two-state boolean advanced/non-advanced state. I think tagging the current GC with capabilities is more flexible than having clients check modes when what they're actually interested in a specific capability associated with that mode. With the capability tagging approach, it's easier to support leading edge features on one platform before other platforms have them, while gracefully degrading on others. Something which is important to developers who are considering whether they should build on swt to get cross platform support, or build on a leading native platform where they know they can always access every last feature. They would prefer a union of feature sets than the intersection. I think it may make the most difference on diagrams than in applictions that mainly use widgets, I'm looking at this from the Draw2D/GEF perspective. If a diagram's running on a platform that's got neat features like blur (for making nice drop shadows), you'll be competing against native apps that make use of it. It's not a functional part of the diagram, so there's no problem just not drawing it when you don't have the capability availble. You'd just want to be able to do something like this: if(gc.isSupported(GC.CAP_BLUR)) { gc.pushState(); gc.setBlur(2.5); gc.setBackground(black); gc.setAlpha(100); gc.fillRect(...); gc.popState(); } gc.fillRect(...);
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
