wxRegion(size_t n, const wxPoint *points, wxPolygonFillMode fillStyle) constructor very slow on Mac

[Karel Heyse]

Hi

I am trying to move OpenCPN (http://opencpn.org/) from wxWidgets 2.8 to 2.9.4.
For some reason, using this new wxWidgets version the function call "wxRegion::wxRegion(size_t n, const wxPoint *points, wxPolygonFillMode fillStyle)" (src/osx/carbon/region.cpp) is VERY slow while in wxWidgets 2.8 it wasn't.
I noticed that this function was completely rewritten. And it appears that "bmp.SetMask(new wxMask(bmp, *wxBLACK));" is one of the statements that makes this new implementation so slow.

Is it possible for someone to check if this is a wxWidgets "bug", please?

The configuration flags I used to compile wxWidgets are:
--enable-unicode --enable-debug --disable-shared --with-libiconv-prefix=/opt/local/ --with-libjpeg --with-libtiff --with-libpng --with-zlib --with-opengl --with-cocoa --without-sdl --disable-sdltest --enable-unicode --enable-display --enable-xrc --prefix=/opt/wxWidgets

My platform is Mac OS X 10.8.3, and I use the default Mac compiler: i686-apple-darwin11-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)

Regards

[Stefan Csomor]

Hi

>I am trying to move OpenCPN (http://opencpn.org/) from wxWidgets 2.8 to
>2.9.4.
>For some reason, using this new wxWidgets version the function call
>"wxRegion::wxRegion(size_t n, const wxPoint *points, wxPolygonFillMode
>fillStyle)" (src/osx/carbon/region.cpp) is VERY slow while in wxWidgets
>2.8 it wasn't.
>I noticed that this function was completely rewritten. And it appears
>that "bmp.SetMask(new wxMask(bmp, *wxBLACK));" is one of the statements
>that makes this new implementation so slow.
>
>Is it possible for someone to check if this is a wxWidgets "bug", please?

Unfortunately it's not a bug, there's no way that I'm aware of to create a
HIShape (native element for a region) from Polygons, QuickDraw is gone, so
I had to remove the workaround I had for 2.9. So right now this is a brute
force route which involves a bitmap which is then striped into rects which
are reassembled into a region.

Probably the best way to move forward is to either use paths for
everything or add a generic region lib Š

Best,

Stefan




>
>

[Karel Heyse]

Does this mean that we should not expect it to be improved in the future? And that this is slow on all platforms?

Regards

Op zondag 7 april 2013 14:23:56 UTC+1 schreef Stefan Csomor het volgende:

[Stefan Csomor]

Hi

>It seems to be a problem of Mac OS X when switching from Carbon (32bit)
>to Cocoa (64bit). QuickDraw has gone in Cocoa and the successor Quartz
>seems not to be implemented in wxWidgets 2.9.x to support wxRegion,
>correct Stefan?

Quartz does not have a native Region construct, 2.9 is using Quartz for
all drawing, but using the HIShape for regions, but there the API for
constructing a region is sadly missing since many years

>The suggestion of Stefan using CGPath or a generic region lib is out of
>my programming knowledge and means also to abandone wxWidgets in this
>part of OpenCPN.

I was saying this, because that's what we have to use to implement it from
within wx. So the plan is to use one of them for wxRegion on OSX/iOS

Best,

Stefan Csomor
>
>

[Gerhard Mueller]

How long it will take to have a usable wx version for Cocoa?
We just think about another way to work out a version of the OpenCPN program when switching the code from wxWidgets to QT.
wxWidgets seems to have too many caveats to get a stable Mac version of OpenCPN. OpenCPN is a program for navigators on boats and other nice software for boaters is also written with QT like zyGrib or qtVlm.

Gerhard

[Stefan Csomor]

Hi Gerhard

How long it will take to have a usable wx version for Cocoa?

it's already usable for many purposes, but as I said there's no way around using a generic polygon scan fill algorithm for cocoa, I've looked for open source version, found one in XServer, I've posted a question on whether the license is ok for us on wx-dev

Best,

Stefan

Am Mittwoch, 10. April 2013 13:05:37 UTC+2 schrieb Stefan Csomor:

Hi

>It seems to be a problem of Mac OS X when switching from Carbon (32bit)
>to Cocoa (64bit). QuickDraw has gone in Cocoa and the successor Quartz
>seems not to be implemented in wxWidgets 2.9.x to support wxRegion,
>correct Stefan?

Quartz does not have a native Region construct, 2.9 is using Quartz for
all drawing, but using the HIShape for regions, but there the API for
constructing a region is sadly missing since many years

>The suggestion of Stefan using CGPath or a generic region lib is out of
>my programming knowledge and means also to abandone wxWidgets in this
>part of OpenCPN.

I was saying this, because that's what we have to use to implement it from
within wx. So the plan is to use one of them for wxRegion on OSX/iOS

Best,

Stefan Csomor
>
>

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.
 
To unsubscribe, send email to wx-users+u...@googlegroups.com
or visit http://groups.google.com/group/wx-users
 
 

[Gerhard Mueller]

Hi Stefan,

thanks for your efforts. Can we been noticed when a solution might be available?
To rewrite OpenCPN in QT will take years I'm afraid.

Gerhard

To unsubscribe, send email to wx-users+...@googlegroups.com
or visit http://groups.google.com/group/wx-users
 
 

[Gerhard Mueller]

Hi Stefan,

just see that now: git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@74049 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

Thank you

Gerhard