There are no available Samebug tips for this exception. Do you have an idea how to solve this issue? A short tip would help users who saw this issue last week.

  • When the pulse logger is on, usual QuantumToolkit.pulse(true) calls PaintCollector.renderAll() in between PulseLogger.pulseStart() and pulseEnd(). renderAll() calls PulseLogger.renderStart() and later renderEnd() is called from the render thread. So all render related pulse logging happens between renderStart and renderEnd. After the fix for RT-19342 in case of live resizing, PaintCollector.liveRepaintRenderJob() calls pulse (false) which prevent renderAll() from calling so renderStart/renderEnd don't get called. So the pulse(false) calls pulseStart, then pulseEnd and then when the render job is added (after the pulse), it starts to call PulseLogger render messages methods, which don't get recorded because renderStart was not called. Later we get warning "unexpected render thread activity". I see 2 or 3 possible solutions to this: 1) call renderStart() inside pulse() if (!collect), this is simplest solution, but it doesn't look right, because we don't actually start render yet. 2) pass some Runnable to the pulse, which in case of usual pulse will be collector.renderAll and in case of live resize all that stuff which now resides in that method. 3) decompose pulse method so the live resize render job can be insterted in the middle of the pulse. Last 2 options will actually change the order of execution, since the render will happen inside the pulse, which I think is a good thing, because it will be consistent with the usual pulse. The least intrusive will probably be option 2.
    via by Vadim Pakhnushev,
    • java.lang.NullPointerException at at at at java.util.concurrent.ThreadPoolExecutor.runWorker( at java.util.concurrent.ThreadPoolExecutor$ at$ at
    No Bugmate found.