How will resolution independence be handled in jdk8?

Stephan Aßmus superstippi at gmx.de
Tue Apr 30 06:00:55 PDT 2013


Am 30.04.2013 13:19, schrieb Scott Palmer:
> On 2013-04-30, at 2:58 AM, Hendrik Schreiber <hs at tagtraum.com> wrote:
>> On Apr 30, 2013, at 2:09 AM, Scott Palmer wrote:
>>> Keep in mind that all this effort to support Swing JButton images or
>>> whatever is really only going to be useful for backward compatiblity with
>>> Swing.  All of the development effort at Oracle appears to be targeting
>>> JavaFX. Therefore if a solution requires API changes to Swing, it is mostly
>>> a waste of time.  JavaFX is the way forward and that is where the
>>> development effort will be concentrated.
>>> As far as I can tell, Swing is in maintenance mode... I doubt any
>>> new development will happen in Swing with the exception of security issues
>>> and bug fixes.
>>
>> Providing multi-resolution images and a Graphics2D that honors them is actually not very Swing specific. It's AWT.
>> JButton is just an example..
>>
>> -hendrik
>
> AWT isn't used by JavaFX either.  I'm not suggesting the issue of resolution dependence doesn't need to be addressed. I'm just pointing out that it is far more likely to get addressed in JavaFX APIs.

What's unfortunate is that the API is already present in AWT. See 
Graphics2D.getDeviceConfiguration() and and 
GraphicsConfiguration.getNormalizingTransform().

This is the introduction to Graphics2D:

"When creating a Graphics2D object, the GraphicsConfiguration specifies 
the default transform for the target of the Graphics2D (a Component or 
Image). [...] The scaling of the default transform is set to identity 
for those devices that are close to 72 dpi, such as screen devices. The 
scaling of the default transform is set to approximately 72 user space 
coordinates per square inch for high resolution devices, such as 
printers. For image buffers, the default transform is the Identity 
transform."

There doesn't need to be any new APIs it would seem. All that's needed 
is that screens don't get the identity transform regardless of their 
actual resolution, even when it is far, far away from 72 units per inch.

With the notion of "user space" coordinates versus "device space" 
coordinates, AWT always has been "resolution independent"

That being said, I am aware that it can be problematic if the majority 
of applications assumes "unit == pixel". But from my own very limited 
experience when trying to work with AWT, my expectation was that it 
would work exactly like advertised. But I was disappointed to find out 
an identity transform is always used for screens regardless.

Best regards,
-Stephan



More information about the macosx-port-dev mailing list