2017-02-21 3:24 GMT+09:00 luchr <[email protected]>: > Let's see if I can answer the question with a concrete example (real > numbers, logged from the code): > > The current code is written in such a way that necessary redraw always, > immediately follows for each rectangle region once the same region has been > cleared. > > The *same* region? I'll don't sign this, because the set of rectangles > (from the draw signal) are heavily changed to get the clearing region, > because they are transformed to Vim rows and columns and *back*. > > Here a concrete example, where I believe one can see, what is happening in > complete detail: > > 19:07:31: draw_event: i=0, Rect: x=453, y=127, w=357, h= 6; > (453,127)--(810,133) > 19:07:31: gui_mch_clear_block: Rows: 8--8, Cols: 1--109 > 19:07:31: clearing Rect: x=10, y=122, w=872, h=15; (10,122)--(882,137) > 19:07:31: gui_gtk3_redraw for x=453, y=127, width=357, height=6 > 19:07:31: redrawing block: rows 8--8, cols=56--100 > > 19:07:31: draw_event: i=1, Rect: x=453, y=133, w= 9, h=231; > (453,133)--(462,364) > 19:07:31: gui_mch_clear_block: Rows: 8--24, Cols: 1--109 > 19:07:31: clearing Rect: x=10, y=122, w=872, h=255; (10,122)--(882,377) > 19:07:31: gui_gtk3_redraw for x=453, y=133, width=9, height=231 > 19:07:31: redrawing block: rows 8--24, cols=56--57 > > Cols 56-100 are redrawn at i=0 and cleared at i=1, but only columns 56-57 > are redrawn. > > Looking at the code my claim is: The columns for the clearing region > 1--Columns are completely decoupled from the columns that are redrawn. > > Does this help? Is this a convincing argument? > No, and you're raising another issue we need to resolve apart from the current issue. Also, the example above even proves that your patch is incorrect since it relies on the same clear-block computation as the current code does, which makes it impossible to explain why the proposed patch resolves the issue in conjunction with your clear-redraw mismatch hypothesis.
You took the word "the same" too strictly for us to continue the discussion productively. You should have already known that the calculation involves char_width, char_height, char_ascent, border_offset of struct Gui and a single pixel compensation to remove possible artifacts caused by double stroke bold as well as x, y, width and height. Because of some correction or adjustment using those variables, literal comparison of pixel numbers does not make much sense, without revealing the rest of all the figures involved. The problem here is that you didn't mention the context nor provide a way to reproduce those numbers in the example. To get this nearly derailed discussion on the right track, I wrote a patch. It tries to fix clear-redraw mismatch and give a neater printf() debug helper. If you will, apply the patch to the latest source, 8.0.344, run `configure` with suitable options as usual, then do `make CFLAGS=-DGTK3_DEBUG` to get an executable having the helper. If you find that those printf()s are placed in wrong places, fix them so that the resulting executable will give output similar to your example (If this is the case, send the modified patch back to us). Run the executable and see if the clear-redraw mismatch is resolved enough to verify your hypothesis and patch, though I don't expect that the patch fixes the original issue. > — > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub > <https://github.com/vim/vim/issues/848#issuecomment-281150155> > > -- > -- > You received this message from the "vim_dev" maillist. > Do not top-post! Type your reply below the text you are replying to. > For more information, visit http://www.vim.org/maillist.php > > --- > You received this message because you are subscribed to the Google Groups > "vim_dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
gtk3-debug.patch
Description: Binary data
