High DPI with FLTK

After switchig to a notebook with higher resolution monitor, I noticed, that the FLTK based ICC Examin application looked way too small. Having worked in the last months much with pixel independent resolutions in QML, it was a pain to see the non adapted FLTK GUI. I had the impression, that despite of several years of a very appreciated advancement of monitor technology, some parts of graphics stacks did not move and take advantage. So I became curious on how to solve high DPI support the hard way.

First of all a bit of introduction to my environment, which is openSUSE Linux and KDE-5¬†with KF5 5.5.3. Xorg use many times a hardcoded default of 96 dpi, which is very unfortune or just a bug? Anyway, KDE follows X11. So the desktop on the high resolution monitor looks initially as bad as any application. All windows, icons and text are way too small to be useable. In KDE’s system settings, I had to set Force Font with DPI and doubled its size from 96 to 192. In the kscreen module I had to set scale 2.0 and then increased the KDE task bars width. Out of the box useability is bad with so many inconsistent manual user intervention. In comparision with the as well tested Unity DE, I had to set a single display scaling factor to 2.0 and everything worked fine and instantly, icons, fonts and window sizes. It would be cool if DE’s and Xorg understand screen resolution. In the tested OS X 10.10 even different screen resolutions of multiple monitors are scaled correctly, so moving a window from a high DPI monitor screen to a traditional low resolution external monitor gives reasonable physical GUI rendering. Apples OS X provides that good behaviour initially, without manual user intervention. It would be interessting how GNOME behaves with regards to display scaling.

Back to FLTK. As FLTK appears to define itself as pixel based, DPI detecion or settings have no effect in FLTK. As a app developer I want to improve user experience and modified first ICC Examin to initially render physically reasonably. First I looked at the FL::screen_dpi() function. It is only a helper for detecting DPI values. FL::screen_dpi() has has in FLTK-1.3.3 hardcoded values of 96DPI under Linux. I noticed XRandR provides correct milimeter based screen dimensions. Together with the XRandR provided screen resolution, it is easy to calculate the DPI values. ICC Examin renderd much better with that XRandR based DPI’s instead of FLTK’s 96DPI. But ICC Examin looked slightly too big. The 192DPI set in KDE are lower than the XRandR detected 227 DPI of my notebooks monitor. KDE provides its forced DPI setting to applications by setting Xft.dpi in XResources. That way all Xft based applications should have the same basic font scaling. KDE and Mozilla apps do use Xft. So add parsing of a Xlib XResources solved that for ICC Examin. The remainder of programing was to programatically scale FLTK’s default font size from 14 pixels with: FL_NORMAL_SIZE = scale(14) . Some more widget sizes, the FtGl font sizes for OpenGL, drawing line widths and graphics scaling where needed. After all those changes, ICC Examin takes now advantage of high resolution rendering inside KDE. Testing under Windows and OS X must follow.

The way to program high DPI support into a FLTK application was basically the same as in QML. However Qt’s QML takes off more tasks by providing a relative font unit, much like CSS em sizes. For FLTK, I would like to see some relative based API’s, in addition to the pixel based API’s. That would be helpful to write more elegant code and integrate with FLTK’s GUI layout program fluid. Computer times point more and more toward W3C technology. FLTK would be helpful to follow.

OpenICC Google Summer of Code 2012 results

Google Summer of Code

Participation of the OpenICC group in the Google Summer of Code 2012 program was this year a great success. All projects reached their respective goals. Here a small summary:

Colour Management for Krita Printing
Joseph Simon worked on adaption and integration of his last years implementation for colour managed printing into Krita/Linux. The workflow is based on ICC profile injection into PDF through the means of a OutputIntent.

KWin Colour Correction
Casian Andrei’s KWin changes for ICC style colour correction in the GPU are reviewed upstream and his new code to the KolorManager code base waits just for approval. The concept follows the X Color Management spec. In contrast to the elder CompICC implementation is the KWin result highly modular and thus very flexible.

Simple Toolkit Abstraction
Nitin Chadas SimpleUI project for rendering a subset of XForms was written from
ground up and provides now backends for FLTK, Gtk and Qt. It needs a bit
of polishing to become useable.

Thanks to Google for providing the colour management and graphics community again a great chance to code and learn the open source way.

ICC Examin-0.51 released

ICC Examin Version 0.51 is a feature release. The package newly explores into window and OpenGL colour correction and contains bug fixes.

Changes overview:

  • new on the fly large gamut intermediate ICC profile
  • new let a colour server colour correct OpenGL
  • new Oyranos colour corrects report window on CPU
  • fix regression in file observation
  • require Oyranos 0.4.0

ICC Examin is a small utility (unix name: iccexamin) for the purpose of watching the internals of ICC v2 and v4 profiles, measurement data (CGATS), colour samples (named colour profiles), gamut visualisations (vrml) and video card gamma tables (Xorg/XFree86/osX).

ChangeLog Version 0.51

Thanks to all contributors and bug reporters.

git git://www.oyranos.org/git/icc_examin
git sha1: 90c55f1a141f17c9cdd1b1e9ae0723306351cc5e
package: http://downloads.sourceforge.net/project/oyranos/ICC Examin/ICC Examin 0.50/icc_examin-0.51.tar.bz2
size: 579532 Byte
sha1sum: 88b951879f304add2670630bd3d0632a0dd39ff7 icc_examin-0.51.tar.bz2
md5sum: e2db40c31596ba2d08cd2612de496289 icc_examin-0.51.tar.bz2
Linux RPM: http://download.opensuse.org/repositories/multimedia:/color_management/

Cross Platform Toolkits and CM

Some readers might wonder, why ICC Examin has not yet a new osX package. There are several issues with FLTK. The most annoying is FLTK has no real colour management policy. But stop. Which cross platform toolkit has? Right – none. Qt has non, Gtk – don’t know? The situation dates from times where RGB was just native display values. But that is changing completely. osX has with SL colour server functionality on top of Quartz integrated. On Linux early prototypes date back to 2008 and start to be integrated as CompIcc project.

Application developers be warned. FLTK and Qt defaults to “Generic RGB” on osX SL. This means no sRGB primaries, alias a different Gamut, and a Gamma of 1.8.

Do not assume sRGB on all platforms. And worse, a application can not assume anything about the colour space of the toolkit. Trolltech and FLTK, and Gnomes Gtk too, can change the underlaying colour space at good will. So colour managed applications using these cross platform toolkits are merciless exposed to this situation.