How will resolution independence be handled in jdk8?
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..
> 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
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
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.
More information about the macosx-port-dev