>We suggest that VTK APIs be pixel-based, for the above reasons and also<br>
>because OpenGL itself is pixel-based. If you agree, we could provide a<br>
>patch for Cocoa windows.<br>
<br>
I agree with this suggestion. If your patch is Cocoa-specific and all
existing tests pass on Cocoa builds with your patch, then go for it.
Just keep an eye on the non-Rogue Cocoa dashboards after your commit.<br>
<br>
Is there conditional code based on Mac OSX version? You didn't submit the patch with your original email...<br><br>
Thx,<br>
David<br>
<br><div><span class="gmail_quote">On 5/22/07, <b class="gmail_sendername">Sean McBride</b> <<a href="mailto:sean@rogue-research.com">sean@rogue-research.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi again everyone,<br><br>How should we interpret the silence on this issue? :)  My guess is that<br>resolution independence is not of immediate concern to anyone, which is<br>fine, and not too surprising.  :)<br><br>That being the case, should we go ahead and commit our patch?  It is
<br>small, and harmless when the scaling factor is 1.0 (the usual case).<br><br>Cheers,<br><br>Sean<br><br><br><br>On 2007-05-10 15:38, Mathieu Coursolle said:<br><br>>Hi vtk developers,<br>><br>>Starting in Mac OS X 
10.4 (and planned to be fully supported in 10.5) is<br>>user interface resolution scaling. This means that the screen coordinate<br>>system is no longer in pixels, but rather in points. Normally, 1 point =<br>>1 pixel, but users might decide to change their settings to set the
<br>>scaling to a value higher than 1. See here for more info on the concept:<br>><<a href="http://en.wikipedia.org/wiki/Resolution_independence">http://en.wikipedia.org/wiki/Resolution_independence</a>><br>>
<br>>For example, let's say we want to create a 100 by 100 window on a system<br>>for which the scale factor is 1.25, then the actual pixel size of the<br>>window would be 125 pixels.<br>><br>>This does not seem to be supported by VTK, as the size of the window is
<br>>assumed to be in pixels, while it is in fact in points on Mac OS X 10.4<br>>and later.<br>><br>>We have a patch to allow VTK to support resolution independence, but<br>>would like some feedback from other vtk developers.
<br>><br>>Q1) Should VTK APIs be pixel-based or point-based?  For example, is the<br>>vtkWindow::GetSize() method meant to return values as pixels?<br>><br>>If so, some additionnal code could be written in the specialized class
<br>>of vtkWindow (ex: vtkCocoaRenderWindow) so that the GetSize() method<br>>returns the actual pixel size of the window rather than its point size.<br>>Of course, the specialized interactors should also convert their screen
<br>>positions from points to pixels.<br>><br>>Q2) How to deal with tests that compare against images?<br>><br>>This brings up another issue. If a 100 x 100 window is created, should<br>>it be 100 pixels or 100 points? If it is 100 points, this means that it
<br>>might not be 100 pixels on screen. If so, most of the dashboard tests<br>>will fail because the comparison images are in pixels.<br>><br>>We suggest that VTK APIs be pixel-based, for the above reasons and also
<br>>because OpenGL itself is pixel-based. If you agree, we could provide a<br>>patch for Cocoa windows.<br><br><br>_______________________________________________<br>vtk-developers mailing list<br><a href="mailto:vtk-developers@vtk.org">
vtk-developers@vtk.org</a><br><a href="http://www.vtk.org/mailman/listinfo/vtk-developers">http://www.vtk.org/mailman/listinfo/vtk-developers</a><br></blockquote></div><br>