kicad-developers team mailing list archive

[Bernhard Stegmaier <stegmaier@xxxxxxxxxxxxx>]

> On 11. Apr 2018, at 19:18, Wayne Stambaugh <stambaughw@xxxxxxxxx> wrote:
> 
> On 4/11/2018 11:02 AM, Bernhard Stegmaier wrote:
>> 
>> 
>>> On 11. Apr 2018, at 16:40, Wayne Stambaugh <stambaughw@xxxxxxxxx
>>> <mailto:stambaughw@xxxxxxxxx>> wrote:
>>> 
>>>> 
>>>> Last point: Is there a list of issue detected with GTK3 ? Some bugs are
>>>> tagged with that ?
>>> 
>>> Not that I am aware of.  Some of the related bug reports may be tagged
>>> with gtk3 but I'm not sure.  If not, that would be a good thing so we
>>> can start correcting some of them during the v6 development cycle.
>> 
>> AFAIK gtk3 also doesn’t support XOR-drawing?
>> So, legacy canvases will probably be as bad or even worse than on macOS…
>> at least, regarding performance.
> 
> I believe (although I could be wrong) all that happened with regard to
> gtk3 is that wxDC == wxGCDC which draws on the advanced
> wxGraphicsContext object which AFAIK supports transparency so XOR
> drawing should not be an issue.  The perform issue can probably solved
> by drawing to a wxMemoryDC first and blitting it to the display.

The thing is how the wxGCDC is implemented on top of gtk? or other stuff.

macOS also uses the wxGCDC but although defined in wxGCDC in the backend/macOS-specific implementation the XOR is just not implemented (but mapped to some other function) because macOS doesn’t support it (it does support a XOR blending mode, but that is different from the logical XOR meant here).

I thought that I read somewhere (long time ago, when I tried to understand why it doesn’t work on macOS) that gtk3 also will not have a logical XOR, but maybe I just got that wrong or things have changed. I didn’t follow up on that.

As far as I can remember Orson made some changes not long ago to redraw everything every time in case of gtk3 (I tested the patch and it was bad for performance on macOS)… this shouldn’t be needed if XOR would work?


Regards,
Bernhard