xulrunner rendering issues ?

Nicolas Mailhot nicolas.mailhot at laposte.net
Mon Apr 7 20:31:53 UTC 2008


Le lundi 07 avril 2008 à 22:01 +0200, Nicolas Mailhot a écrit :
> Le lundi 07 avril 2008 à 21:39 +0200, Ralf Ertzinger a écrit :
> > Hi.
> > 
> > On Mon, 07 Apr 2008 13:58:57 +0200, Denis Leroy wrote
> > 
> > > I think you summarized it pretty well. To be accurate, the VMWare 
> > > problem is not DPI reporting (which is correct, as per xrdb -query),
> > > but the screen *size* reporting (in millimeters).
> > 
> > Well... what size does a virtual screen have?
> 
> vmware should probably match the virtual screen pixel size to the
> current display real pixel size, and report the corresponding physical
> size. Since it matches a virtual pixel to a real pixel, that would be
> the correct thing to do IMHO.

To elaborate a little more, I think you have close-to-eyes screens and
distant screens. The dpi of anything in the first category should never
be manipulated and kept to the real value (as in, take a ruler, measure
physical size, count pixels, make ratio). That takes care of computer
screens and embedded gadgets. The dpi of anything is the second category
can not easily be measured. Computing an ideal perceived dpi value would
need something to measure distance to viewers, assuming the distance is
not dynamic and every viewer is at the same distance. So "angles of
view" are not a realistic engineering concept. Instead, you can get by
with heuristics, like anything in SD video resolution is ~ x dpi
equivalent, anything in HD resolution is ~ y dpi equivalent, projectors
that use a computer resolution are ~ 100 dpi equivalent (for now, that
will probably change in the future), etc. And for virtual screens you
match to whatever pixel density the actual screen you're rendering on
uses.

And all this should be done at the kernel/Xorg level, with app writers
focusing on a way to share font size prefs (via xsettings, dbus or
whatever is the cool tech of the day), instead of second-guessing the
system (badly).

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20080407/9f8238c9/attachment.sig>


More information about the fedora-devel-list mailing list