Community
Participate
Working Groups
Build ID: I20081211-1908 Right now, figures are blissfully ignorant of the zoom level that lies between them and the screen; however, how they draw themselves should be a function of that zoom level in some cases. Scaling Down: When rendering themselves to an outline view, there's no point wasting time drawing text or an icon that's going to be 3 pixels high on screen. It may make more sense to draw a gray box instead of text, or use a lower resolution icon. Scaling Up: On the other end of the scale, at +400% zoom icons start to look pretty crummy because they're scaled up from a tiny image file, and it would hurt performance to scale down a higher resolution one all the time. Again, if the figure knows its true size on screen, it could load an appropriate resource. Performance Gain: The outline view makes every figure on a diagram consult whatever model is behind it for information, regardless of whether that information is going to get communicated to a user. For example, text in labels of figures that are too small to read in the outline view, and off the page in the main view. Querying the model for those parameters, or listening to it for changes, can be costly and could be avoided until the full sized figure is within the bounds of the main view. Feature gain: This can be used to implement "semantic zoom" where a figure substantially morphs through zoom levels, for example just showing a "C" icon for a class on a UML diagram in the outline view instead of a full class box, or annotating it with extra details when zoomed in sufficiently. Implementation: If Graphics just had some property the figure could check in its paint method to make that decision, then it could render differently. I say "some property" because there's room for different designs there. It could be: - an arbitrary integer/enum "level of detail" - the zoom level, effectively a screen pixels/drawn pixel resolution - the real world resolution, in pixels/inch (combination of zoom level, and Device.getDPI()'s resolution) Anyone have thoughts on this? Useful? Priority? Preference of implementation? Other ideas of how it could be used?
levelOfDetail = determinant(graphics.getTransform()); where levelOfDetail is the area covered by a transformed 1x1 pixel square.
(In reply to comment #1) > levelOfDetail = determinant(graphics.getTransform()); > > where levelOfDetail is the area covered by a transformed 1x1 pixel square. > I assume that's a suggestion for its implementation since Graphics doesn't have a public getTransform() method yet, and that it carries implied support for the general idea. Are you suggesting I add a public getTransform() method to graphics so clients can calculate the level of detail themselves, or would that be wrapped into a method in Graphics? It sounds to me like option 2, providing the scale factor, but that one transform may not account for the full method call to screen chain of transforms. For example, a ScaledGraphics wrapping an SWTGraphics both with scale factors set. Also, is it a vote against mixing in Device.getDPI()? -------------- On a side note, I was thinking of what tools would be helpful to make use of the feature. One I've thought of so far is a multi-resolution Image class to return an appropriately detailed copy of the same image based on the LOD factor. Anyone have some other ideas?
