|
|
Home » Community » U++ community news and announcements » Painter refactored/optimized
|
Re: Painter refactored/optimized [message #50535 is a reply to message #50534] |
Tue, 13 November 2018 11:52 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Yes. Begin()/End() around DoPaint(); equally fixes the issue with PainterExamples. But I think it would be nice to have a clean table after BufferPainter::Create()... Of course, I understand that each re-initialized variable increases the cost towards full constructor/destructor pair.
Best regards,
Tom
|
|
|
|
|
Re: Painter refactored/optimized [message #50538 is a reply to message #50537] |
Tue, 13 November 2018 12:50 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
The issue is still there in SVN 12531 if you do my above changes to PainterExamples. (Obviously, adding Begin/End will still remove the issue.)
I can't figure out what exactly you changed in Create though. Or am I working on a completely wrong SVN version?
Best regards,
Tom
|
|
|
|
Re: Painter refactored/optimized [message #50540 is a reply to message #50539] |
Tue, 13 November 2018 14:06 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
OK, the file was correctly updated. (Reverting my changes simultaneously slightly misguided me to believe otherwise.)
Anyway the problem is still there: The transformation matrix does not get reset to identity in Create.
Best regards,
Tom
|
|
|
|
|
Re: Painter refactored/optimized [message #50546 is a reply to message #50542] |
Wed, 14 November 2018 10:57 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi Mirek,
As of r12533 Create now works as expected
However, there seems to be a severe performance issue with MT. In some cases MT can be three times slower than MT before this optimization round. E.g. a vector map rendering in 20 ms with previous MT and in 40 ms with ST now takes 60 ms with new MT.
This is somehow related to changing transformations (of course within Begin/End pairs) which is now extremely expensive, especially when using MT.
Thanks and best regards,
Tom
EDIT: I created a transformation intensive view that shows a matrix of just 90 symbols. Each of the symbols are drawn with strokes and fills using a different translation for each within a Begin/End pair. Rendering of this same view takes only 2.2 ms with ST but a whopping 45 ms with MT! Using PreClip or not does not have any observable effect on the result.
[Updated on: Wed, 14 November 2018 11:37] Report message to a moderator
|
|
|
|
Re: Painter refactored/optimized [message #50548 is a reply to message #50547] |
Wed, 14 November 2018 13:39 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
You can test with PainterExamples by enabling MT and running Benchmark with OnPath and OnTextPath examples.
Best regards,
Tom
EDIT: 'Pythagoras Tree Image' example portrays this slowdown too. Every other PainterExamples example running MT is on par or faster compared to ST. With my 4C8T Intel Core i7 the best MT gain is about 4x compared to ST. This is common with images and fills. Narrow geometries do not gain so much boost from MT landing at 1x-2x speed improvement.
[Updated on: Wed, 14 November 2018 14:03] Report message to a moderator
|
|
|
Re: Painter refactored/optimized [message #50549 is a reply to message #50548] |
Wed, 14 November 2018 14:38 |
|
mirek
Messages: 13980 Registered: November 2005
|
Ultimate Member |
|
|
Tom1 wrote on Wed, 14 November 2018 13:39Hi,
You can test with PainterExamples by enabling MT and running Benchmark with OnPath and OnTextPath examples.
Best regards,
Tom
EDIT: 'Pythagoras Tree Image' example portrays this slowdown too. Every other PainterExamples example running MT is on par or faster compared to ST. With my 4C8T Intel Core i7 the best MT gain is about 4x compared to ST. This is common with images and fills. Narrow geometries do not gain so much boost from MT landing at 1x-2x speed improvement.
I have found that BeginOnPath was conservatively flushing rendering pipeline for no good reason, so that is now optimized out. TextOnPath is still slower if you fill the letters, that will have to wait till next batch of optimization I am afraid.
In fact, what is slow is alternating solid color / non-solid color fills - that is the case for both Pythagoras Tree Image and TextOnPath... Will have to think if there is anything I can do there...
[Updated on: Wed, 14 November 2018 14:40] Report message to a moderator
|
|
|
|
Re: Painter refactored/optimized [message #50551 is a reply to message #50550] |
Wed, 14 November 2018 14:56 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
Absolutely! I'm extremely motivated to help you squeeze every single extra millisecond out of the rendering times in Painter!
OnPath show now 1.4x improvement over ST and OnTextPath about 2.3x improvement... And these were over ST not over previous MT where improvement is 5x that. Well done Mirek!
A question --- removed ---
Best regards,
Tom
EDIT: Removing question. Something else is now slowing down my code. It may be related to translations (Xform2D).
[Updated on: Wed, 14 November 2018 15:07] Report message to a moderator
|
|
|
|
Re: Painter refactored/optimized [message #50553 is a reply to message #50552] |
Wed, 14 November 2018 15:55 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
My translated symbols are simply solid black over white background. The ST vs. MT speed ratio is about 15..20x in favor of ST. They were about equally fast when compiled against r.11960.
I need to find a pattern here. There is no clear Begin/End dependency as far as I can see. I'm trying to narrow down the code to find a test case.
Best regards,
Tom
|
|
|
|
Re: Painter refactored/optimized [message #50557 is a reply to message #50554] |
Thu, 15 November 2018 10:14 |
Tom1
Messages: 1216 Registered: March 2007
|
Senior Contributor |
|
|
Hi,
I finally figured out a way to share this test case. I send you code and a Serialized Painting to test. (Actually, this can be quite handy for any Painter performance issue testing in general.) Here's the code:
#include <CtrlLib/CtrlLib.h>
#include <Painter/Painter.h>
using namespace Upp;
class PainterBench : public TopWindow {
public:
Painting p;
FileSel fs;
void Open(){
if(fs.ExecuteOpen("Select a painting to view")){
p.Clear();
p.Serialize(FileIn(fs.Get()));
}
}
virtual bool Key(dword key, int count){
switch(key){
case K_CTRL_O:
Open();
return true;
}
return false;
}
typedef PainterBench CLASSNAME;
PainterBench(){
Sizeable();
}
virtual void Paint(Draw &draw){
int64 STtiming=0;
int64 MTtiming=0;
ImageBuffer ib(GetSize());
{
BufferPainter bpainter(ib);
bpainter.Co(true);
bpainter.PreClipDashed();
bpainter.Clear(White());
bpainter.EvenOdd();
int64 t0=usecs();
bpainter.Paint(p);
int64 t1=usecs();
MTtiming=t1-t0;
}
{
BufferPainter bpainter(ib);
bpainter.Co(false);
bpainter.PreClipDashed();
bpainter.Clear(White());
bpainter.EvenOdd();
int64 t0=usecs();
bpainter.Paint(p);
int64 t1=usecs();
STtiming=t1-t0;
}
SetSurface(draw,Rect(ib.GetSize()),ib,ib.GetSize(),Point(0,0));
double gain=(double)STtiming/(double)(0.1+MTtiming); // Avoid div by zero
Title(Format("Rendering MT took %lld us, ST took %lld us, MT gain is %.2f",MTtiming,STtiming,gain));
}
};
GUI_APP_MAIN
{
PainterBench().Run();
}
There are two Serialized painting files to test with: SomeRocks.painting exhibits the MT slowdown issue dramatically. The other file is just for checking how fast a typical map view renders.
Best regards,
Tom
|
|
|
|
Goto Forum:
Current Time: Wed May 15 04:03:55 CEST 2024
Total time taken to generate the page: 0.02499 seconds
|
|
|