On Thu, Feb 04, 2016 at 01:00:59AM +0900, Kazunobu Kuriyama wrote: > 2016-02-03 23:59 GMT+09:00 Marius Gedminas <[email protected]>: > > On Wed, Feb 03, 2016 at 11:10:22PM +0900, Kazunobu Kuriyama wrote: > > > Looking at the pictures you kindly uploaded, I can see what is cleared by > > > vim still remains on the screen. It's just like as if clear window/block > > > clear operations were intentionally skipped > > > > But not all of them -- just some character cells! And only when > > scrolling forwards -- hitting PageUp redraws the screen correctly! > > > > It's as if clearing works, but outputting "text with spaces" skips > > clearing the background behind each space character. > > > > This additional info is quite helpful, from which we know where to start. > > While there're several issues we have to solve, let's focus on the "scroll > forward" issue for now. It's easier to attack than the visual quarks, that > is, vague enemies like ghosts :)
I've patched vim to log all calls to gui_gtk2_draw_string() and wrote a small Python script to visualize the draw calls using ncurses. Here's a screencast: https://asciinema.org/a/35507 The interesting part starts at about second 35: when I press PageDown, vim clears the window by drawing a lot of spaces: Drawing a string at (2,0): ' ' clearing (2,0): 149 cells Drawing a string at (3,0): ' ' clearing (3,0): 149 cells ... Drawing a string at (19,0): ' ' clearing (19,0): 149 cells and then it draws additional help text -- just words -- on top of the cleared area: Drawing a string at (2,22): 'Visual' clearing (2,22): 6 cells Drawing a string at (2,29): 'mode' clearing (2,29): 4 cells Drawing a string at (2,34): 'command' clearing (2,34): 7 cells Drawing a string at (2,50): 'v_' clearing (2,50): 2 cells Drawing a string at (2,59): ':help' clearing (2,59): 5 cells Drawing a string at (2,65): 'v_u' clearing (2,65): 3 cells Drawing a string at (2,80): ' ' clearing (2,80): 69 cells Drawing a string at (3,22): 'Insert' clearing (3,22): 6 cells Drawing a string at (3,29): 'mode' clearing (3,29): 4 cells Drawing a string at (3,34): 'command' clearing (3,34): 7 cells This all works correctly in my ncurses visualizer -- but when the real gvim draws this, it's as if those 149-cell whitespace strings were not drawn at all. Or, to be more precise, cleared. The 'clearing ... 149 cells' messages in the log prove that this bit of code set_cairo_source_rgb_from_pixel(cr, gui.bgcolor->pixel); cairo_rectangle(cr, FILL_X(col), FILL_Y(row), num_cells * gui.char_width, gui.char_height); cairo_fill(cr); was executed, so it remains to be discovered why it didn't clear anything. Was there an active clipping rectangle? Was bgcolor->pixel wrong? I'll try to add more debugging printfs(). You can find the visualizer script, the draw call log, and the vim patch that adds debug printfs() in this gist: https://gist.github.com/mgedmin/de3663d9fd5d32b2c779 On Thu, Feb 04, 2016 at 01:35:15AM +0900, Kazunobu Kuriyama wrote: > Oh, one thing to ask you. > > When scrolling forward, which side of the screen begins messing up on > drawing, upper side or lower side? I can't tell -- it's too fast. Regards, Marius Gedminas -- The First and Second Rules of Program Optimisation: 1. Don't do it. 2. (For experts only!): Don't do it yet. -- Michael A Jackson -- -- 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.
signature.asc
Description: Digital signature
