Hi, dillo developers! I observed another nasty bug in Dillo dev-3.1 Maybe it is known. If so, excuse my ignorance. :) When the option buffered_drawing=2 for double buffering and the browser window is resized by the user, it seems that the back buffer is drawn on the screen too early after the reallocation and is full of garbage instead of the rendered page. This way, during the resizing, very heavy flicker appears, which IMHO is not good for double buffering drawing scheme. Best Regards -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
Hi John, On Mon, Feb 29, 2016 at 09:16:03AM +0200, John Found wrote:
Hi, dillo developers!
I observed another nasty bug in Dillo dev-3.1
Maybe it is known. If so, excuse my ignorance. :)
When the option buffered_drawing=2 for double buffering and the browser window is resized by the user, it seems that the back buffer is drawn on the screen too early after the reallocation and is full of garbage instead of the rendered page.
This way, during the resizing, very heavy flicker appears, which IMHO is not good for double buffering drawing scheme.
with buffered_drawing=2 dillo uses the Fl_Double_Window class from FLTK, so the result should be similar to e.g. the test/fonts program from FLTK. Do you have it available and can test how that program feels when resizing on your system? In my setup I only get some light flickering at the scroll bars with buffered_drawing=2. Whereas I see heavy flickering with buffered_drawing=0. Do you see any difference between buffered_drawing=0 and buffered_drawing=2? Cheers, Johannes
On Tue, 1 Mar 2016 22:54:34 +0100 Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
with buffered_drawing=2 dillo uses the Fl_Double_Window class from FLTK, so the result should be similar to e.g. the test/fonts program from FLTK. Do you have it available and can test how that program feels when resizing on your system? In my setup I only get some light flickering at the scroll bars with buffered_drawing=2. Whereas I see heavy flickering with buffered_drawing=0. Do you see any difference between buffered_drawing=0 and buffered_drawing=2?
Yes. These are different kind of flickering. On buffered_drawing=0 I see how Dillo redraws the page content on the window surface. No artifacts, only normal redraws one after another. On buffered_drawing=1 is approximately the same but a little bit rarely. While on buffered_drawing=2, when the user resize the window, the whole window becomes full of garbage - this is specific kind of garbage. It happens when you reuse some memory previously used to store images with different sizes and then allocate it for a new image and draw it on the screen as it is. A mess of graphical scanlines, rectangles full of color, distorted images of different kind. Unfortunately, I can't get screenshot, because it is a dynamic effect. After stopping resizing window, the last redraw is OK. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
On Wed, Mar 02, 2016 at 06:41:21AM +0200, John Found wrote:
On Tue, 1 Mar 2016 22:54:34 +0100 Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
with buffered_drawing=2 dillo uses the Fl_Double_Window class from FLTK, so the result should be similar to e.g. the test/fonts program from FLTK. Do you have it available and can test how that program feels when resizing on your system? In my setup I only get some light flickering at the scroll bars with buffered_drawing=2. Whereas I see heavy flickering with buffered_drawing=0. Do you see any difference between buffered_drawing=0 and buffered_drawing=2?
Yes. These are different kind of flickering. On buffered_drawing=0 I see how Dillo redraws the page content on the window surface. No artifacts, only normal redraws one after another. On buffered_drawing=1 is approximately the same but a little bit rarely.
While on buffered_drawing=2, when the user resize the window, the whole window becomes full of garbage - this is specific kind of garbage. It happens when you reuse some memory previously used to store images with different sizes and then allocate it for a new image and draw it on the screen as it is. A mess of graphical scanlines, rectangles full of color, distorted images of different kind.
Unfortunately, I can't get screenshot, because it is a dynamic effect. After stopping resizing window, the last redraw is OK.
As buffered_drawing=2 uses Fl_Double_Window from FLTK which in turn tries to use the Xorg DOUBLE-BUFFER extension, you might want to try xdpyinfo | grep DOUBLE-BUFFER to see if this extension is enabled on your system and either disable or enable it in your xorg.conf to see if that makes a difference.
On Wed, 2 Mar 2016 21:48:22 +0100 Johannes Hofmann <Johannes.Hofmann at gmx.de> wrote:
As buffered_drawing=2 uses Fl_Double_Window from FLTK which in turn tries to use the Xorg DOUBLE-BUFFER extension, you might want to try xdpyinfo | grep DOUBLE-BUFFER to see if this extension is enabled on your system and either disable or enable it in your xorg.conf to see if that makes a difference.
DOUBLE-BUFFER extension is enabled and running on my system. I made some experiments disabling it in the config file and restarting X. Checked it's presence with "xdpyinfo | grep DOUBLE-BUFFER" and it was missing. Then the ugly flashing artifacts disappeared from Dillo and with buffered_drawing=2 the flickering still appears, visually similar to that of buffered_drawing=1, but much less intrusive. All tests are made by loading some page in the browser and then dragging the window edge in order to resize the window. -- http://fresh.flatassembler.net http://asm32.info John Found <johnfound at asm32.info>
participants (2)
-
Johannes.Hofmann＠gmx.de -
johnfound＠asm32.info