bugMyPaint - Bugs: bug #18765, Cursor size as visual feedback

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #18765: Cursor size as visual feedback

Submitted by:  Mihai Cozma <meeshoo>
Submitted on:  Fri 30 Sep 2011 11:13:59 PM UTC  
 
Severity: 3 - NormalPriority: 5 - Normal
Status: DuplicatePrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: 0.9.1 + gitPlanned Release: None
Operating System: Linux Mint 11

(Jump to the original submission Jump to the original submission)

Sat 05 Jan 2013 01:30:49 PM UTC, comment #8:

Duplicate of bug #18765

Jon Nordby <jonnor>
Project Administrator
Sun 02 Oct 2011 11:23:01 AM UTC, comment #7:

Hey, thanks for the input. I remember calling get_effective_radius() instead of get_actual_radius() at some point and I got an error saying there is no such thing. the same with get_color_rgb(). I think there is a problem with initialization there that I miss or something. I'll try to dig deeper.

Also thanks for the profiling tips, I'll look into it.

Don't have much spare time, but I'll let you know as soon as I have any progress on it. I'll start with porting your experiment and making work on current git version, "first things first" :).

Mihai Cozma <meeshoo>
Sun 02 Oct 2011 10:55:08 AM UTC, comment #6:

In current git, get_actual_radius has been renamed to get_effective_radius, and it's still only an estimate. There is no such thing as the "correct" cursor radius. Brushes can change their radius based on pressure, speed, or by adding jitter to the dab positions. What we have is only an estimate; for simple brushes it will be correct (and cursor.py does correct for the zoom level). Just look at the implementation of get_effective_radius() in lib/brush.py, it doesn't take any dynamics into account.

The estimate could be made better by a) more clever math or b) a "cursor_size" brushsetting that allows to fine-tune the displayed radius for every brush individually, if required.

About multicore, I doubt it's worth the effort with the current code. For updating the cursor positions, we are basically wasting CPU cycles with unnecessaray work because it was easier to code. Not much point to add all the complexity of multi-threading, when the CPU cycles are still wasted on compositing and rotating all layers again and again for every move of the cursor.

If you want to optimize, I recommend to start by profiling the current code to get a feeling for what the hotspots are. Personally I like to use the "perf" utility for this because it will also show you work done inside X11 and libraries; for the python side, have a look at tests/README.profiling; and tests/test_performance.py may be useful.

Martin Renold <martinxyz>
Project Administrator
Sat 01 Oct 2011 11:14:28 PM UTC, comment #5:

I've managed to integrate all your experiment into the latest git version with one exception: "get_color_rgb" call in OnCanvasCursor in cursor.py doesn't seem to work and throws an error, although I have set it before on color picking. Anyway, I used gray color, I don't think that changes the experiment too much, as it is all about brush size, but I would really want to know how I should fix this.

First of all, the get_actual_radius function implemented in brush.hpp doesn't seem to approximate correctly the size of the brush at various zoom levels. Maybe the math behind brush scaling has changed, I will need a confirmation on that.

Second, I don't think this is a big performance hit. It is true I run a quite powerful machine (i7 based desktop), but I didn't notice slowdowns because of our drawn cursor particularly. While it is true that if I zoom out and draw things around with a big brush, it will work very slow, but it does so even without drawing any cursor at all.

So my conclusions are:

1. This should definitely be in the git version as there are people using fast computers nowadays, with a switch in options menu to turn it off. If you could provide me with a fix for the "get_color_rgb" and a hint about how "get_actual_radius" should work to return the proper radius, I think I can submit a patch with everything, including the options switch, without you having to bother with all the details.

2. The code for drawing is definitely slow for bigger images and should be improved. I heard about new photoshop versions using the power of multi-core machines and hardware acceleration to do this. I think i could also look into this once the original problem is solved.

Mihai Cozma <meeshoo>
Sat 01 Oct 2011 09:44:54 PM UTC, comment #4:

Ok, some progress, I've managed to include all your experimental cursor stuff into the latest git build. Now I got to the point where I get the same error as the error I get from the old experimental build, hopefully I'll get passed it and get the thing working.

Mihai Cozma <meeshoo>
Sat 01 Oct 2011 08:36:28 PM UTC, comment #3:

Hmm, the code does compile but it has some errors, I guess because of the newer version of GTK I have on my system. Will it work if I get the current version of MyPaint and just copy/paste the cursor in there?

Mihai Cozma <meeshoo>
Sat 01 Oct 2011 06:49:49 AM UTC, comment #2:

It would probably be interesting to have this code in master even if it is too slow, together with a preference where it can be enabled for testing or for very fast systems.

Martin Renold <martinxyz>
Project Administrator
Sat 01 Oct 2011 06:46:27 AM UTC, comment #1:

The size limitation comes from X11. The alternative is to draw the cursor on the canvas ourselves, see https://gitorious.org/~maxy/mypaint/maxy-experimental/commits/cursor_fun for an experiment with that. This allows to visualize other interesting things like intuos tilt.

The main problem is that it is slow; for the large ones the lag can become very irritating while painting. We already use the GPU indirectly through Cairo for zooming/rotating if it is available, but in general the code that displays the canvas is rather slow. You notice when dragging the canvas while zoomed out.

If you can figure out a way to get the FPS high enough to draw an interactive cursor even when zoomed out, that would be very welcome.

A "cheaper" alternative would to draw the cursor shape on-canvas only while you resize it.

Martin Renold <martinxyz>
Project Administrator
Fri 30 Sep 2011 11:13:59 PM UTC, original submission:

I've been told to make this a separate bug, so here it is.

The problem with the cursor size is that it does not reflect the actual size of the brush stroke. Its radius is clamped by a hardcoded minimum value on the small side and by the maximum supported cursor by GTK on the current display for the big value.

This is an issue because usually the first stroke is only a "try stroke" to try the actual size of the brush, followed by an Undo. If you need to dabble with the brush size between range [maxCursorSize;infinite] its all about trial an error until you get the right size for the job.

I've been looking into cursor.py file and it seems that the limitation comes from GTK itself. Isn't there any other way to approach this, something like a custom vector based cursor (circle for starters) that is displayed at actual cursors' position?

The generation of the circle would have to happen only on cursor resizing, so that would not be a problem. The only issue I can think about is for some kind of flickering when painting, but it cannot be that bad. If it turns out to be unbearable, how about using the GPU for displaying everything in there, that would solve the problem?

Mihai Cozma <meeshoo>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by jonnor (Posted a comment)
  • -unavailable- added by martinxyz (Posted a comment)
  • -unavailable- added by meeshoo (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sat 05 Jan 2013 01:30:49 PM UTCjonnorStatusConfirmed=>Duplicate
      Open/ClosedOpen=>Closed
    Sat 01 Oct 2011 06:46:27 AM UTCmartinxyzStatusNone=>Confirmed
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup