Pixel width "Thickness" for shapes

Pixel width "Thickness" for shapes

• Juergen Wenz

  Thanks to all for responding.

  Andrew's info on the SnapsToDevicePixels was a great help.

  I did some testing and the zoom out problem is real. The lines disappear at some zoom factor between 0.1 and 0.01. (I did not try to quantify it further).

  There is a work around I quickly tested where you can ScaleTransform the canvas and then loop through the children multiplying the the StrokeThickness by the inverse of the ScaleTransform.

  Maybe someone would consider a StrokeThicknessScale as boolean modifier to stop the ScaleTransform scaling the stroke thickness if set to True for individual elements and for all the childrem of the element.

  
  

• MasterG152

  excerpt:

  As I was saying earlier, to accommodate the high-resolution displays, we need to get developers to stop specifying coordinates in physical pixels. Alas, we also have determined that after decades of training, people tend to think in physical pixels.

  To solve this quandary, we have made the units for MIL operations to be "logical pixels" or "device independent pixels" (but we thought dips would be insulting to some people <G>). Logical pixels are really 1/96 of an inch, because that is what most desktop CRTs use. Of course, in the future this 1/96" will be relegated to history books as all displays go to super-high densities, but the goal will still be achieved. By having all units of measurements based on physical units (inches) instead of pixels, we can now gracefully scale the display.

  
  

• AnswerFinder

  If you want to recreate the appearance of GDI+ the set SnapsToDevicePixels="True".

  HTH,

  Andrew

  
  

• Chronous

  I was simply quoting external sources, the ones below should be a good starting point:

  http://www.64bit-world.com/forums/microsoft-public-developer-winfx-avalon/10074-what-exaclty-logical-pixel-avalon.html

  http://windowssdk.msdn.microsoft.com/library/default.asp url=/library/en-us/wcp_conceptual/html/b96bed40-8946-4285-8fe4-88045ab854ed.asp

  http://danielcrowleywilson.blogspot.com/2005/09/device-independent-pixels-in-windows.html

  http://blogs.msdn.com/marcelolr/archive/2004/12/03/274213.aspx

  
  

• bljacobs

  I assume this was taken from somewhere else. Can you tell me the source

  I don't want to specify a single pixel, I want the drawing to use the pixels I have!

  The WPF drawing does look not as sharp as the GDI drawing on the same monitor simply because each line is using more than one physical pixel.

  Also, when working with a model of a physical object, I want to indicate plane breaks or edges with a line that is as narrow as possible. A single pixel ine is perfect!

  With the current WPF, when I scale the model, the line at the edge of the object scales resulting in say a 10 thickness line for 5X scaling. It is just an indicator of the model edge and I'd prefer a single pixel line.

  
  

• Zeeshan Gulzar

  I agree, this feature would be very helpful in mapping software too - to keep the stroke thickness invariable when the zoom factor changes.
  
  
  

• dbunder

  I thought about some of the issues involved and this is quite a serious problem.

  Individually transforming the shapes is not realistic in a complex drawing with thousands of elements. The canvas transform is elegant.

  Consider a material handling conveyor system with a width of 34". You want a wire frame model with a thin line at each edge to define the conveyor. You chooses a scale factor for the canvas of 96:1 so the width of the conveyor is depicted in 34 pixels.

  Each line defining the edges must have a thickness of 1. So if you zoom in 5x then the lines have a thickness of 5.

  Also, and worse, with a conveyor system the size of a football field, when you zoom out, do the lines disappear and you lose the drawing

  Can we not have a StrokeThickness modifier eg StrokeThicknessScale as boolean (or similar) where one needs the shape to scale dimensionally but the line thickness to stay the same

  
  

• William Screen

  Seema,

  That's great news. I'm glad someone's listening, and it sounds like you may have had the "StrokeThicknessScale/UsePhysicalPixel" requirment on the radar for some time. I look forward to an implementation.

  Cheers,

  Rana

  
  

• Mighty-O

  Hi Seema

  Can you elaborate on "Depending on how the Zoom:Thickness binding is specified" please

  I am currently changing the StrokeThickness as the zoom is changed but it is slow and there are some artifacts.

  The speed is obvious when viewing an AutoCAD drawing with say 800 lines and using the mousewheel to zoom. There is a noticeable delay that is annoying.

  Alexander Stevenson (MSFT) suggested I zoom the geometry rather than the path and this works well except the delay is even worse. I apply the same scaletransform to every entity geometry and then change the value of the ScaleX, ScaleY on the transform. It looks like there is a sequential re-render as it takes forever (some seconds) for each scale change.

  The artifacts are that the visual line widths are not consistent for example, adjacent horizontal and vertical lines sometimes appear to have different widths depending on the zoom factor.

  Any ideas would be helpful.

  Thanks

  John

  
  

• L.A

  Hi folks,

  Avalon was geared towards a set of v1 features and unfortunately we did not hit all of them. You are right -- nominal pen widths is a great feature for many applications. We plan to offer the ability to specify certain Avalon features in device pixels in vNext.

  Depending on how the Zoom:Thickness binding is specified, the aforementioned ScaleTransform solution should work well.

  - SeemaR@MS

  
  
  

• AMG44

  Thanks Andrew,

  I did a side by side on the same model with SnapsToDevicePixels="True". Much sharper.

  Anyone got a method to keep the line thickness at 1 even when scaled

  
  

• Randall Moore

  johnvarney wrote:

  Thanks Andrew, I did a side by side on the same model with SnapsToDevicePixels="True". Much sharper. Anyone got a method to keep the line thickness at 1 even when scaled

  I don't know of any way specifically however an option might be rather than to scale the shapes you could transform each of the points in the shape. Less elegant sure but it would ensure the line thickness doesn't grow.

  
  

• Cridal

  Thanks Darius

  I agree. The device independence is great.

  Except when the data, such as a map, chart, engineering drawing, satellite image or such like, needs to use a physical pixel.

  In AutoCAD, for example, engineers routinely buy the largest, highest dpi display they can get. They can then show a large amount of data and zoom in on the area of interest.

  Restricting WPF to 1/96 inch minimum is throwing away all that capability. There needs to be a mechanism to use the physical pixel - such as the suggested StrokeThicknessScale, or maybe a UsePhysicalPixel mode, or both!

  
  

• Chris L60969

  Darius,

  The issue I have with "logical pixels" is when there is a need to draw a specific color at a specific pixel the current rendering system does not faithfully draw it. Sometimes it draws an approximated color, not the one I specified. So, if I don't care about accuracy of the color at a pixel then rendering is fine. WPF apparently can not consistently draw non-anti-aliased lines. And for some applications, such as charts and graphs, thats an issue.

  This is not to say that WPF rendering is not fantastic, because it is fantastic, obviously, for many applications. But I think you'll continue to see a steady stream of people asking why they're not allowed to draw on a per pixel basis. Imop, its not that people are just used to thinking of drawing in a per-pixel way, its that drawing in a per pixel way fulfills a need that anti-aliasing does not. Sure, per-pixel drawing its not scalable, and thats a problem. So how about adding the ability to draw lines that aren't anti-aliased on a monitor, but are still scalable

  Regards,

  Rana

  
  
• Pixel width "Thickness" for shapes