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 08 Aug 2009 01:15:33 PM UTC  
Severity: 4 - ImportantPriority: 5 - Normal
Status: Works For MePrivacy: Public
Assigned to: NoneOpen/Closed: Closed
Release: Planned Release: None
Operating System: 

Sun 29 Jun 2014 02:07:24 AM UTC, 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 04 Jan 2013 10:48:32 PM UTC, 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 23 Oct 2010 01:30:52 PM UTC, 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 14 Sep 2010 07:14:50 PM UTC, 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 08 Aug 2009 01:15:33 PM UTC, 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 29 Jun 2014 02:07:24 AM UTCachadwickStatusWish=>Works For Me
    Sat 23 Oct 2010 01:30:52 PM UTCjonnorStatusWorks For Me=>Wish
      Summary[Usability] Missing feedback when brush overloads CPU=>[Usability] Feedback when brush overloads CPU
    Tue 14 Sep 2010 07:14:50 PM UTCmartinxyzStatusConfirmed=>Works For Me
    Fri 20 Aug 2010 05:24:07 PM UTCjonnorSeverity3 - Normal=>4 - Important
      Summaryfeedback missing when brush overloads CPU=>[Usability] Missing feedback when brush overloads CPU
    Sun 07 Feb 2010 01:12:29 PM UTCjonnorStatusNone=>Confirmed
    Show feedback again

    Back to the top

    Powered by Savane 3.1-cleanup