bugMyPaint - Bugs: bug #14094, [Usability] Feedback when brush...

Show feedback again

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

bug #14094: [Usability] Feedback when brush overloads CPU

Submitted by:  Martin Renold <martinxyz>
Submitted on:  Sat Aug 8 13:15:33 2009  
Severity: 4 - ImportantPriority: 5 - Normal
Status: Works For MePrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: Planned Release: None
Operating System: 

Sun Jun 29 02:07:24 2014, comment #4:

We now queue up events Python-side too, to make event capture return faster. The queue is processed in idle callbacks in chunks, much like layer moves. A side effect of this is that when rendering is greatly slower than capture, rendering appears to trail the brush - happily this is only appreciable for huge swipes of large-radius brushes, which the user may expect to be slow anyway.

I consider this a pretty effective way of showing overload and letting the artist slow down their inputs.

Closing as WORKSFORME since we're migrating bugs to Github now; if anyone wants to work on this further - especially that interesting-sounding mt stuff - please open a new issue about it over there.


This bug tracker will shortly be moving to github. As part of this
process, we're reviewing old bug reports on gna.org and moving
them over. Please report new bugs at the new locations:

https://github.com/mypaint/mypaint/issues for the mypaint app, or
https://github.com/mypaint/libmypaint/issues for its brushlib

Andrew Chadwick <achadwick>
Project Administrator
Fri Jan 4 22:48:32 2013, comment #3:

With the support for queued/deferred processing that went in for MyPaint 1.1 (to improve performance), it is now feasible to implement this.
Proposal for how this can be done:

  • Let end_atomic() on a surface just return an invalidated region, without actually processing it.

For MyPaintTiledSurface this just means to keep things around in the OperationQueue.

  • Introduce a new function process_area() that allows to process an given area.

Because we may want to process tile-wise, it should return the area actually processed. One call of the function should process a chunk small enough to not delay the caller for too long (but big enough to make use of multithreading). When everything has been processed, the return value should indicate this.

  • In MyPaint, call the process_tile from a glib idle handler that is repeated until processing is done.

This concept is very similar to how GEGL operates.

Jon Nordby <jonnor>
Project Administrator
Sat Oct 23 13:30:52 2010, comment #2:

I disagree. From a user standpoint feedback in this case is definitely wanted. I do not think it is a safe assumption that the user will just stop painting and wait when this situation occurs.

Reopening as a wish, since there is no consensus this is a real "bug".

Jon Nordby <jonnor>
Project Administrator
Tue Sep 14 19:14:50 2010, comment #1:

To be honest, I'm thinking now that the current behaviour is okay.

The situation of a perceived crash (more than 10s waiting time) is very rare with modern CPUs. Often a least the start of the stroke is visible. The lack of feedback causes the user to slow down anyway.

Talking to myself, I guess. Closing.

Martin Renold <martinxyz>
Project Administrator
Sat Aug 8 13:15:33 2009, original submission:

MyPaint does not update the display when the brush engine is overloaded, possibly leaving the user with the impression that it has crashed.

Implementation notes:

As a first remedy, showing the "busy" cursor would already help slightly. Technically we just process GTK events in order. Motion events have a higher priority than expose events. What we want it something like "at least one display update every 0.5 seconds".

It might be a bad idea to queue away the motion event for later playback, because other events (eg. brush resize by keyboard, or undo, or canvas dragging) will then arrive out of order.

Ideally, the stroke rendering can be canceled by pressing ESC or similar (eg. pressing undo).

Martin Renold <martinxyz>
Project Administrator


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 achadwick (Posted a comment)
  • -unavailable- added by jonnor (Updated the item)
  • -unavailable- added by martinxyz (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.


    Error: not logged in



    Follow 10 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Sun Jun 29 02:07:24 2014achadwickStatusWish=>Works For Me
    Sat Oct 23 13:30:52 2010jonnorStatusWorks For Me=>Wish
      Summary[Usability] Missing feedback when brush overloads CPU=>[Usability] Feedback when brush overloads CPU
    Tue Sep 14 19:14:50 2010martinxyzStatusConfirmed=>Works For Me
    Fri Aug 20 17:24:07 2010jonnorSeverity3 - Normal=>4 - Important
      Summaryfeedback missing when brush overloads CPU=>[Usability] Missing feedback when brush overloads CPU
    Sun Feb 7 13:12:29 2010jonnorStatusNone=>Confirmed
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup