[Dillo-dev] resolution independent px

2 views
Skip to first unread message

Johannes Hofmann

unread,
Jan 16, 2015, 2:51:40 AM1/16/15
to dill...@dillo.org
Hi,

attached is a patch that would enable resolution independent
handling of px as described in [1].
It would result in roughly equally sized images on high and low
resolution devices at the cost of a higher overhead for additional
image scaling.
Is there a need for something like this?
Should it be enabled via config option or should we do it
automatically if we detect a DPI value that differs a lot from
the standard value?

Cheers,
Johannes

[1] http://www.w3.org/TR/CSS2/syndata.html#x39
resolution_independent_px.diff

Jorge Arellano Cid

unread,
Jan 16, 2015, 10:15:58 AM1/16/15
to dill...@dillo.org
On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote:
> Hi,
>
> attached is a patch that would enable resolution independent
> handling of px as described in [1].
> It would result in roughly equally sized images on high and low
> resolution devices at the cost of a higher overhead for additional
> image scaling.

A long time ago, image scaling was relatively low overhead,
but since dillo got correct gamma correction, it became much
more expensive.

I remember testing this and the difference was noticeable.
It was left anyway because the amount of scaled images
in the average web page is low.


> Is there a need for something like this?

I don't know...

> Should it be enabled via config option or should we do it
> automatically if we detect a DPI value that differs a lot from
> the standard value?

For me, it is hard to say without knowing the main use of it.
What I do know is that our scaling is CPU intensive, so I tend
to have it off unless necessary.

Another way around is to optimize our gamma correction algorithm
with integer arithmetic. An option that was not taken at the time
because of the above stated reasons.

HTH.

--
Cheers
Jorge.-

_______________________________________________
Dillo-dev mailing list
Dill...@dillo.org
http://lists.dillo.org/cgi-bin/mailman/listinfo/dillo-dev

Sebastian Geerken

unread,
Jan 16, 2015, 10:49:28 AM1/16/15
to dill...@dillo.org
On Fr, Jan 16, 2015, Jorge Arellano Cid wrote:
> On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote:
> > Hi,
> >
> > attached is a patch that would enable resolution independent
> > handling of px as described in [1].
> > It would result in roughly equally sized images on high and low
> > resolution devices at the cost of a higher overhead for additional
> > image scaling.
>
> A long time ago, image scaling was relatively low overhead,
> but since dillo got correct gamma correction, it became much
> more expensive.

It is not so much gamma correction, but some improvements before. BTW:
if you look at dw/fltkimgbuf.cc, you see that the old fast code is
still available, by setting scaleMode to SIMPLE. Perhaps this should
be configurable (should be simple), or depending on estimated CPU
performance.

If you run dillo (3.1-dev, not 3.0.4.1) with the attached page, change
the window width, and compare the results with Firefox, you'll notice
that Firefox responds a bit faster. I'm not sure whether Firefox
scales faster, but in other circumstances I've noticed that Firefox
seems to apply two scaling algorithms: one simple but fast one, with
higher priority, and a better but slower one, which is applied with
lower priority.

Sebastian

slow-scaling.html
signature.asc

Johannes Hofmann

unread,
Jan 17, 2015, 9:03:01 AM1/17/15
to dill...@dillo.org
On Fri, Jan 16, 2015 at 12:14:19PM -0300, Jorge Arellano Cid wrote:
> On Fri, Jan 16, 2015 at 08:50:13AM +0100, Johannes Hofmann wrote:
> > Hi,
> >
> > attached is a patch that would enable resolution independent
> > handling of px as described in [1].
> > It would result in roughly equally sized images on high and low
> > resolution devices at the cost of a higher overhead for additional
> > image scaling.
>
> A long time ago, image scaling was relatively low overhead,
> but since dillo got correct gamma correction, it became much
> more expensive.
>
> I remember testing this and the difference was noticeable.
> It was left anyway because the amount of scaled images
> in the average web page is low.
>
>
> > Is there a need for something like this?
>
> I don't know...
>
> > Should it be enabled via config option or should we do it
> > automatically if we detect a DPI value that differs a lot from
> > the standard value?
>
> For me, it is hard to say without knowing the main use of it.
> What I do know is that our scaling is CPU intensive, so I tend
> to have it off unless necessary.

It's only useful if you have a high resolution device where DPI is
much higher than about 70. In that case images will be rendered
very small.

I currently don't have such a device, so personally I don't have
any need for this now. I just wanted to get feedback from dillo-dev
in case someone already ran into this issue.

Cheers,
Johannes

James C

unread,
Jan 18, 2015, 3:21:38 AM1/18/15
to dill...@dillo.org
Hi Johannes,

Reading the link, it looks like normally viewed displays with any
resolution between about 50 DPI and 140 DPI will have one CSS pixel
exactly equal to one device pixel; so resolutions outside that are the
definition of 'differs a lot' in the standard.

What's the overhead of asking the library to re-scale the image to the
size that it already is? If it's significant, then maybe there needs
to be a special case for 1:1.

I start out with a bias against adding another run-time option, but
it's based on my not-very-relevant experience of adding an option to
dpid.

Contradicting myself, the standard implies that there could be an
option for viewing distance, in which case there could be a special
case to that option for 'never scale'.

Regards.
James.

Johannes Hofmann

unread,
Jan 18, 2015, 2:33:12 PM1/18/15
to dill...@dillo.org
Hi,

On Sun, Jan 18, 2015 at 09:20:06PM +1300, James C wrote:
> Hi Johannes,
>
> Reading the link, it looks like normally viewed displays with any
> resolution between about 50 DPI and 140 DPI will have one CSS pixel
> exactly equal to one device pixel; so resolutions outside that are the
> definition of 'differs a lot' in the standard.
>
> What's the overhead of asking the library to re-scale the image to the
> size that it already is? If it's significant, then maybe there needs
> to be a special case for 1:1.

the overhead is significant in case images would not be scaled
otherwise, so we would want to special case it somehow.

>
> I start out with a bias against adding another run-time option, but
> it's based on my not-very-relevant experience of adding an option to
> dpid.
>
> Contradicting myself, the standard implies that there could be an
> option for viewing distance, in which case there could be a special
> case to that option for 'never scale'.

As nobody actually has a problem at the moment I think we can
postpone this. It will come up again as high resolution devices are
becoming more popular.

Cheers,
Johannes

eocene

unread,
Jan 18, 2015, 3:22:50 PM1/18/15
to dill...@dillo.org
Johannes wrote:
> As nobody actually has a problem at the moment I think we can
> postpone this. It will come up again as high resolution devices are
> becoming more popular.

Speaking of high resolution devices, does it look like there's much
value these days in trying to get dillo to work better in the world
of touch interfaces, or has dillo been utterly passed by there for
one reason or another?

Sebastian Geerken

unread,
Jan 18, 2015, 3:44:42 PM1/18/15
to dill...@dillo.org
On So, Jan 18, 2015, Johannes Hofmann wrote:
> As nobody actually has a problem at the moment I think we can
> postpone this. It will come up again as high resolution devices are
> becoming more popular.

Furthermore, if such devices become more common, web designers may
become more aware of this problem; something like this

----------------------------------------------------------------------
Some text and an image:
<img src="http://www.dillo.org/Icons/ProgramIcon32.png"
style="min-height: 1em">
----------------------------------------------------------------------

would solve the problem, too (test it with different font sizes in
dillo 3.1-dev).

Sebastian

signature.asc
Reply all
Reply to author
Forward
0 new messages