Texture painting slow down with mouse, but not with tablet #33935

New Issue

Danny McGrath · 2013-01-19T19:25:30+01:00

Danny McGrath commented

2013-01-19 19:25:30 +01:00

%%%--- Operating System, Graphics card ---
Ubuntu 12.04, Nvidia 550 Ti

- Blender version with error, and version that worked ---

50627 and blelow works, 50628 and up is broken

- Short description of error ---

Since the affected version, if painting with the mouse is very choppy (unless you move very slow), yet it is perfectly fine and fluid when using the tablet.

A sample video of the problem can be found at: http://download.blender.org/ftp/incoming/temp/tex_paint_mouse_slowdown.ogv

In the video, the white and red paint strokes are with the mouse, the green are with the tablet.

I was able to get some assistance from Antony Riakiotakis on irc, but he was not able to reproduce/test without a tablet. I have attached the the patch and resulting log that he sent me to display the events as attachments to this report.

- Steps for others to reproduce the error (preferably based on attached .blend file) ---

Open Image editor and add a new image with the defaults
Enable image painting
Paint with the mouse and observe choppyness
Paint with tablet and it is nowhere near as bad
%%%

%%%--- Operating System, Graphics card --- Ubuntu 12.04, Nvidia 550 Ti - Blender version with error, and version that worked --- 50627 and blelow works, 50628 and up is broken - Short description of error --- Since the affected version, if painting with the mouse is very choppy (unless you move very slow), yet it is perfectly fine and fluid when using the tablet. A sample video of the problem can be found at: http://download.blender.org/ftp/incoming/temp/tex_paint_mouse_slowdown.ogv In the video, the white and red paint strokes are with the mouse, the green are with the tablet. I was able to get some assistance from Antony Riakiotakis on irc, but he was not able to reproduce/test without a tablet. I have attached the the patch and resulting log that he sent me to display the events as attachments to this report. - Steps for others to reproduce the error (preferably based on attached .blend file) --- - Open Image editor and add a new image with the defaults - Enable image painting - Paint with the mouse and observe choppyness - Paint with tablet and it is nowhere near as bad %%%

Danny McGrath commented

2013-01-19 19:25:30 +01:00

Changed status to: 'Open'

Antonis Ryakiotakis commented

2013-01-19 19:35:45 +01:00

%%%The choppiness cause is apparent: we handle less mousemove(and more mouseinbetween) events in the paint modal function when using the mouse. I am guessing this means more mousemove getting queued and less beeing handled. This causes the paint code to use linear interpolation between the last two event positions (causing choppiness).
In my opinion 50628 (which is colour management merge), simply introduced more code to execute and thus made the difference between the two event paths readily apparent. My question is why do we get more mousemove events for tablet? Maybe this is an OS issue emtting more mouse move events for blender, yet maybe it's ghost unbalancing the two event paths. Of course this may have to do with our paint code too but I can't find some reason that colour management will introduce any kind of difference between the two event paths.%%%

%%%The choppiness cause is apparent: we handle less mousemove(and more mouseinbetween) events in the paint modal function when using the mouse. I am guessing this means more mousemove getting queued and less beeing handled. This causes the paint code to use linear interpolation between the last two event positions (causing choppiness). In my opinion 50628 (which is colour management merge), simply introduced more code to execute and thus made the difference between the two event paths readily apparent. My question is why do we get more mousemove events for tablet? Maybe this is an OS issue emtting more mouse move events for blender, yet maybe it's ghost unbalancing the two event paths. Of course this may have to do with our paint code too but I can't find some reason that colour management will introduce any kind of difference between the two event paths.%%%

Sergey Sharybin commented

2013-01-21 11:01:15 +01:00

%%%I doubt the culprit is caused by color management merge -- the same color management would be applied for mouse and tablet. I could not confirm the issue with 2.64 and 2.65 releases. Also what a heck you're using development snapshot of 2.63 for reference, would rather you confirm the issue using official builds from blender.org or builder.blender.org.%%%

Danny McGrath commented

2013-01-21 12:22:53 +01:00

%%%Me? I was only using dev for the in between stuff, but 2.63 and 2.65a tests were official downloads from blender.org (I keep last few releases installed here). I used the revision numbers from those splash screens to use for the dozen or so compiles I used to bisect, and Antony and I narrowed it down to 50628. Only spent 4 hours compiling or so to narrow it down for the report. (Note to self: make lite!!!)

45996 - works (2.63 release)
49567 - works
50470 - works
50583 - works
50612 - works
50626 - works
50627 - works
50628 - broken
50629 - broken
50633 - broken
50640 - broken
50696 - broken
50921 - broken
51372 - broken
53177 - broken (2.65a release)
%%%

%%%Me? I was only using dev for the in between stuff, but 2.63 and 2.65a tests were official downloads from blender.org (I keep last few releases installed here). I used the revision numbers from those splash screens to use for the dozen or so compiles I used to bisect, and Antony and I narrowed it down to 50628. Only spent 4 hours compiling or so to narrow it down for the report. (Note to self: `make lite`!!!) 45996 - works (2.63 release) 49567 - works 50470 - works 50583 - works 50612 - works 50626 - works 50627 - works 50628 - broken 50629 - broken 50633 - broken 50640 - broken 50696 - broken 50921 - broken 51372 - broken 53177 - broken (2.65a release) %%%

Antonis Ryakiotakis commented

2013-01-21 12:49:53 +01:00

%%%Sergey, I doubt it too. As I said, I think it's probably an event issue Maybe http://projects.blender.org/tracker/index.php?func=detail&aid=20667&group_id=9&atid=498 is related, or at least gives hints as to the cause?%%%

Sergey Sharybin commented

2013-01-22 10:50:12 +01:00

%%%Antony, i'm not sure. Will try with home desktop and if i'll notice some slowdown i could bisect in that case. Seems i don't have the issue on laptop..

Dan, please try builds from http://builder.blender.org/download/ It could be some differences in our build configurations..%%%

%%%Antony, i'm not sure. Will try with home desktop and if i'll notice some slowdown i could bisect in that case. Seems i don't have the issue on laptop.. Dan, please try builds from http://builder.blender.org/download/ It could be some differences in our build configurations..%%%

Brecht Van Lommel commented

2013-01-31 15:03:06 +01:00

%%%Antony, I might be misunderstanding this, but isn't the problem the other way around? The resulting lines from painting with the mouse don't look choppy, it seems that it's the performance that is choppy.

So it might be that it's the mouse that is generating more mousemove events than the tablet, and the handling of all those mousemove events is what is slowing things down. If that's the case, then the solution could be to ensure that the slow color management operation happens only once per redraw, and not N times if there are N mousemove events between redraws.

One solution would be to somehow pass these events as a group to operators, the mousemove event could have some extra data that gives all the previous inbetween mousemove coordinates in an array, and then they could all be handled at once by the operator. Another would be to somehow postpone the color management operation to the draw function, though this may be tricky with partial updates.%%%

%%%Antony, I might be misunderstanding this, but isn't the problem the other way around? The resulting lines from painting with the mouse don't look choppy, it seems that it's the performance that is choppy. So it might be that it's the mouse that is generating more mousemove events than the tablet, and the handling of all those mousemove events is what is slowing things down. If that's the case, then the solution could be to ensure that the slow color management operation happens only once per redraw, and not N times if there are N mousemove events between redraws. One solution would be to somehow pass these events as a group to operators, the mousemove event could have some extra data that gives all the previous inbetween mousemove coordinates in an array, and then they could all be handled at once by the operator. Another would be to somehow postpone the color management operation to the draw function, though this may be tricky with partial updates.%%%

Danny McGrath commented

2013-01-31 15:14:00 +01:00

%%%Just to add to the report, from irc we figured out that changing the input color space to Non-Color makes the mouse go just as fast as the tablet.%%%

Sergey Sharybin commented

2013-01-31 15:24:51 +01:00

%%%Brecht, currently partial rect update happens after every stroke step. This worked much better than handling the whole frame on display (we noticed this when doing madpainting during Mango).

Could see quite simple solution here: instead of doing immediate partial update, store a AABB of all invalid rects and recalculate it display-time. If mousemove happens indeed much more often than redraws, that'd be a solution.%%%

%%%Brecht, currently partial rect update happens after every stroke step. This worked much better than handling the whole frame on display (we noticed this when doing madpainting during Mango). Could see quite simple solution here: instead of doing immediate partial update, store a AABB of all invalid rects and recalculate it display-time. If mousemove happens indeed much more often than redraws, that'd be a solution.%%%

Antonis Ryakiotakis commented

2013-01-31 16:15:45 +01:00

%%%Hi, the performance is what it is. When the dab takes long to calculate, dab generation code does linear interpolation, making the stroke linear instead of 'curvy'. I don't think mouse vs tablet forces a separate path of calculations so my take on this is that it must be event related. There's even difference between the two input devices on the event log posted here.

In my opinion it's the opposite: More events for tablet are queued, sampling the interemediate positions better. whether this happens on ghost level or on OS level is what I don't know, Of course doing calculations cheaper will help too.%%%

%%%Hi, the performance is what it is. When the dab takes long to calculate, dab generation code does linear interpolation, making the stroke linear instead of 'curvy'. I don't think mouse vs tablet forces a separate path of calculations so my take on this is that it must be event related. There's even difference between the two input devices on the event log posted here. In my opinion it's the opposite: More events for tablet are queued, sampling the interemediate positions better. whether this happens on ghost level or on OS level is what I don't know, Of course doing calculations cheaper will help too.%%%

Sergey Sharybin commented

2013-02-07 18:06:48 +01:00

%%%Dan, could you please test whether fix33935.patch makes things working fine for you? (patch is attached to the report)%%%

Danny McGrath commented

2013-02-07 18:44:42 +01:00

%%%hmmm, no luck, it is worse overall I think. In fact, it seems to make the tablet equally bad too. Changing from sRGB to non color data works fine for both still though.%%%

Sergey Sharybin commented

2013-02-07 19:46:51 +01:00

%%%This is very weird to hear actually =\ With the patch applied CM code would be run on display only, no color space conversion during stroke or so. Redraws shouldn't happen more often than brush strokes and i would expect anything but speed regressions.

Fortunately, i do have another patch for you to test. It shall make painting on byte image with default sRGB display just fast. However, it wouldn't affect on painting speed on float image (not sure, it is also a regression in speed when painting on float image caused by new color management?)

Patch is called fix33935_2,patch%%%

%%%This is very weird to hear actually =\ With the patch applied CM code would be run on display only, no color space conversion during stroke or so. Redraws shouldn't happen more often than brush strokes and i would expect anything but speed regressions. Fortunately, i do have another patch for you to test. It shall make painting on byte image with default sRGB display just fast. However, it wouldn't affect on painting speed on float image (not sure, it is also a regression in speed when painting on float image caused by new color management?) Patch is called fix33935_2,patch%%%

Danny McGrath commented

2013-02-07 20:04:50 +01:00

%%%Ok, I reverted the first patch and applied the second and it works great. As expected, 32bit floats are still slow and tablet normal.%%%

Sergey Sharybin commented

2013-02-07 20:14:53 +01:00

%%%I'll cleanup patch a bit and will commit tomorrow. However, not currently sure how to solve 32bit floats. Are they fast in 2.63a when you paint with mouse?%%%

Danny McGrath commented

2013-02-07 20:18:17 +01:00

%%%No, 32bit floats were still slow, but non 32bit floats with mouse were fast%%%

Sergey Sharybin commented

2013-02-08 09:22:51 +01:00

%%%I've commited patch so now painting on byte images shall be as fast as it was before CM changes.

However, your last comment blew my mind away ;) what does it mean "non 32bit floats"? What i wanted to ask is: in 2.63a create 32bit float image with default dimension and try to paint on it with mouse and tablet. Compare speed of mouse/tablet when painting on 32bit float in 2.63a. Further, get a recent trunk build from http://builder.blender.org/download/ (revision shall be 54381 at least) and do the same paint on 32bit float image. How speed of mouse/tablet would be in comparison with how it was in 2.63a? Would it be any dramatic slowdown?%%%

%%%I've commited patch so now painting on byte images shall be as fast as it was before CM changes. However, your last comment blew my mind away ;) what does it mean "non 32bit floats"? What i wanted to ask is: in 2.63a create 32bit float image with default dimension and try to paint on it with mouse and tablet. Compare speed of mouse/tablet when painting on 32bit float in 2.63a. Further, get a recent trunk build from http://builder.blender.org/download/ (revision shall be 54381 at least) and do the same paint on 32bit float image. How speed of mouse/tablet would be in comparison with how it was in 2.63a? Would it be any dramatic slowdown?%%%

Danny McGrath commented

2013-02-08 15:17:34 +01:00

%%%Sorry hehe, by "non 32bit floats" I meant not having the "32bit float" option checked.

Using my own compiled r54388, everything is fine with both mouse and tablet in sRGB/Raw/Non-Color, and choppy mouse/fast tablet in all the others. I assume that you only do this change for just sRGB instead of all of them?

Also you confuse me now with identical test targets:

"in 2.63a create 32bit float image with default dimension and try to paint on it with mouse and tablet. Compare speed of mouse/tablet when painting on 32bit float in 2.63a.  Further, get a recent trunk build from http://builder.blender.org/download/ (revision shall be 54381 at least) and do the same paint on 32bit float image."

So you want me to compare 32bit floats in 2.63a with 32bit floats in 2.63a? hehe. I am also curious wth I have to retest 2.63a again!?

Further, I think my own compiles are just fine, don't you? I mean, it's only been several years that I have been compiling blender, and not once have I had an issue with my build that would cause such a problem, especially when I have already tested a buildbot build twice for this, and proven that the results are the same as my own compile. Waiting 20 min on a download gets annoying ;)%%%

%%%Sorry hehe, by "non 32bit floats" I meant not having the "32bit float" option checked. Using my own compiled r54388, everything is fine with both mouse and tablet in sRGB/Raw/Non-Color, and choppy mouse/fast tablet in all the others. I assume that you only do this change for just sRGB instead of all of them? Also you confuse me now with identical test targets: ``` "in 2.63a create 32bit float image with default dimension and try to paint on it with mouse and tablet. Compare speed of mouse/tablet when painting on 32bit float in 2.63a. Further, get a recent trunk build from http://builder.blender.org/download/ (revision shall be 54381 at least) and do the same paint on 32bit float image." ``` So you want me to compare 32bit floats in 2.63a with 32bit floats in 2.63a? hehe. I am also curious wth I have to retest 2.63a _again_!? Further, I think my own compiles are just fine, don't you? I mean, it's only been several years that I have been compiling blender, and not once have I had an issue with my build that would cause such a problem, especially when I have already tested a buildbot build twice for this, and proven that the results are the same as my own compile. Waiting 20 min on a download gets annoying ;)%%%

Sergey Sharybin commented

2013-02-08 15:23:41 +01:00

%%%I only optimized unneeded colorspace conversion when image's space == display space. In this case no color space conversion is needed. If image space != display space, conversion shall still happen and there's no way to optimize it further.

What i'm trying to understand now is: is there speed regression when painting on float images when comparing current trunk with 2.63a. It's still not clear for me..%%%

%%%I only optimized unneeded colorspace conversion when image's space == display space. In this case no color space conversion is needed. If image space != display space, conversion shall still happen and there's no way to optimize it further. What i'm trying to understand now is: is there speed regression when painting on float images when comparing current trunk with 2.63a. It's still not clear for me..%%%

Danny McGrath commented

2013-02-08 15:33:55 +01:00

%%%Well, as I mentioned in the last reply, your patch makes mouse and tablet work equally well now in trunk, and is the same speed as in 2.63 release I tested against here. Does that not answer your question?

Pop by irc perhaps for a few quick questions and save this report from a conversation if you got time, I'm on now.%%%

%%%Well, as I mentioned in the last reply, your patch makes mouse and tablet work equally well now in trunk, and is the same speed as in 2.63 release I tested against here. Does that not answer your question? Pop by irc perhaps for a few quick questions and save this report from a conversation if you got time, I'm on now.%%%

Sergey Sharybin commented

2013-02-10 10:01:35 +01:00

%%%Checked on code further. Before new color management float buffers were converting to display space using optimized lookup table, without interpolation even it seems. New color management is a bit more generic level and always applies accurate transform. That'd describe why painting on floats could be slower than it was in 2.63a.

On the other hand, before new color management, the whole image buffer used to be re-calculated to display space, which could be slow. Now we'er doing partial updates which i expect should be faster.

Further, i don't currently see why switching from immediate partial update to partial update when display happens would slowdown things for you. For me painting is much faster when using delayed partial update. Please try builds from http://download.blender.org/ftp/incoming/blender_paint_speed/ and compare speed of painting with speed in 2.65a.%%%

%%%Checked on code further. Before new color management float buffers were converting to display space using optimized lookup table, without interpolation even it seems. New color management is a bit more generic level and always applies accurate transform. That'd describe why painting on floats could be slower than it was in 2.63a. On the other hand, before new color management, the whole image buffer used to be re-calculated to display space, which could be slow. Now we'er doing partial updates which i expect should be faster. Further, i don't currently see why switching from immediate partial update to partial update when display happens would slowdown things for you. For me painting is much faster when using delayed partial update. Please try builds from http://download.blender.org/ftp/incoming/blender_paint_speed/ and compare speed of painting with speed in 2.65a.%%%

Danny McGrath commented

2013-02-10 19:24:54 +01:00

%%%I tried the 64bit blender paint speed binary and to me it seems identical to previous tests of 2.65a; 16bit is fine, 32bit is slow/choppy still :(%%%

Sergey Sharybin commented

2013-02-11 14:25:37 +01:00

%%%As discussed in IRC, after rev54463 seems everything to eb fine now, so closing the report :)%%%

Sergey Sharybin commented

2013-02-11 14:25:37 +01:00

Changed status from 'Open' to: 'Resolved'

Sergey Sharybin closed this issue

2013-02-11 14:25:37 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Texture painting slow down with mouse, but not with tablet #33935