- Dillo-dev - lists.mailman3.com

resolution independent px

by sgeerken＠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

Jan. 16, 2015

resolution independent px

by jcid＠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.-

Jan. 16, 2015

resolution independent px

by Johannes.Hofmann＠gmx.de

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

Jan. 16, 2015

background images

by eocene＠gmx.com

Saw another case today where a forum had quoted text obscured by repeated background quotation marks. Playing around a little, the behaviour seems flaky (html and image files attached).

Jan. 15, 2015

different rendering depending on DOCTYPE

by Johannes.Hofmann＠gmx.de

Hi, I noticed, that firefox and chrome render stuff differently depending on the DOCTYPE. Attached is a small example. firefox doesn't show overlapping text but dillo does. When the DOCTYPE line is removed firefox renders the page as dillo does. Wikipedia has some information about the topic at [1]. I think at some point we need to handle these cases too. It would also be interesting which rule exactly prevents firefox from showing overlapping text when the DOCTYPE line is present. Cheers, Johannes [1] http://en.wikipedia.org/wiki/Quirks_mode

Jan. 11, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Tue, Jan 06, 2015, Sebastian Geerken wrote: > On Sun, Dec 28, 2014, Sebastian Geerken wrote: > > On Wed, Dec 24, 2014, eocene wrote: > > > - source is slow to render, seemingly something to do with large tables. > > > > Yes, I'm noticing that rendering large tables is much slower than in > > 3.0.4. I'll work on this. (Probably a side-effect of GROWS.) > > It has become much better, although still slower than 3.0.4. A simple gprof run showed another opportunity for optimization. There should now be no performance problems anymore with tables. Sebastian

Jan. 7, 2015

what's currently broken in dillo

by sgeerken＠dillo.org

On Sun, Dec 28, 2014, Sebastian Geerken wrote: > On Wed, Dec 24, 2014, eocene wrote: > > - source is slow to render, seemingly something to do with large tables. > > Yes, I'm noticing that rendering large tables is much slower than in > 3.0.4. I'll work on this. (Probably a side-effect of GROWS.) It has become much better, although still slower than 3.0.4. Sebastian

Jan. 6, 2015

Core-dump pasting from one form field into another

by Johannes.Hofmann＠gmx.de

On Sat, Dec 27, 2014 at 08:42:55PM +0100, Johannes Hofmann wrote: > On Sat, Dec 27, 2014 at 06:22:12PM +0000, eocene wrote: > > James wrote: > > > This is exercisable in Dillo 3.0.4.1, but not new. I found it by > > > accident in my hack-up of Dillo 3.0.4. > > > > > > The reproduction is: > > > - enable cookies for .google.com > > > - navigate to https://mail.google.com/mail/?ui=html > > > - fight the links until you get a screen with two fields, one for the > > > username and one for the password > > > - type something into the username field > > > - select it and drag to the password field > > > -- core dump > > > > > > I am on: > > > > > > - OSX 10.6.8 > > > - Dillo 3.0.4.1 with SSL enabled > > > - FLTK 1.3.3 > > > - with dpid, etc from Dillo 3.0.4 with extensive hacking > > > > > > so the fault could be Mac-specific. > > > > I tried playing around a little, on linux and not having a gmail acct, > > and nothing wanted to go wrong, so, yeah, it might be an osx issue... > > Can't reproduce it either on DragonFly BSD. I can try later to get > a stack trace on osx. On MacOSX all attempts to drag and drop crash dillo for me. As it also causes confusion on X11 based systems I disabled DND alltogether for now. Cheers, Johannes

Jan. 6, 2015

should we have a dillo-announce list?

by jcid＠dillo.org

On Sat, Jan 03, 2015 at 07:49:29PM +0000, eocene wrote: > > Seems like a release announcements list would be valuable... +1 At least that way we'd have one official channel (without the burden of receiving the whole traffic in dillo-dev). -- Cheers Jorge.-

Jan. 6, 2015

what's currently broken in dillo

by jcid＠dillo.org

On Mon, Jan 05, 2015 at 03:59:15PM +0100, Sebastian Geerken wrote: > On Fr, Jan 02, 2015, Jorge Arellano Cid wrote: > > It's a bit sad to find time and again that 3.0.4 has better rendering > > than the new branch. (e.g. [1]) > > > > [1] http://actualidad.rt.com/economia/161785-china-devastador-dolar-rublo-yuanes > > It is getting better (fixing "plain" bugs). While examining why the > images are not shown, I noticed that some element is set at height 0. > Test the attached page in dillo and Firefox and notice the difference: > Firefox shows the first line, although it has height 0, but draws the > second line at the same position as the first, the latter shining > through. > > It is somewhat difficult to imitate this behavour [1]; but two > solutions are feasable: (i) ignore height (perhaps via user style > sheet); (ii) use 'height' only to make elements larger (somewhat > similar to 'adjust_min_width'). In both cases, the two lines would be > put on top of each other. I like (ii). It falls in the "make dillo decide when directives make no sense" philosophy I'm advocating for.. -- Cheers Jorge.-

Jan. 6, 2015