On 9 June 2015 at 22:54, Nicolai Hess <[email protected]> wrote: > > > 2015-06-09 18:03 GMT+02:00 Igor Stasenko <[email protected]>: > >> >> >> >> >> >> the easiest way to reproduce it would be: >> - allocate a new surface of such dimensions, that its buffer size will be >> aligned with 4k page boundary (a smallest one would be 1x1024, or 1024x1, >> since one pixel is 4 bytes) >> - try to blit this surface with bitblt >> - crash >> >> (sure it happens not always, since often there could be another memory >> page allocated for other purposes with read access granted, >> but if you continuously do that, you will inevitable face the crash) >> > > Thank you for your feedback, > but still no "luck" - no crash. > > Do you remember if this happens on windows at all or only on mac? > > Dunno. I had it on my mac. Sure it may depend on how OS/C libs allocating memory.
Anyways, since we're talking about using bitmaps as fill patterns for cairo, it should be safe as long as bitblt never involved with it. Actually registering surfaces with bitblt required only if they used in operations like copying their contents to Display form require this workaround, since it involves bitblt primitive(s). For the rest of cases (and if one day, hopefully we stop using bitblt altogether), the need in this workaround can be completely eliminated. So the issue can be localized if we split implementation and make a subclass, lets say CairoMorphicCompatibleSurface, where we move all registering logic together with workarounds, and in basic class simply throw exception on attempt to use it #asForm. > > > >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
