On 8 May 2015 at 22:20, Nicolai Hess <[email protected]> wrote: > > > 2015-05-08 21:42 GMT+02:00 Igor Stasenko <[email protected]>: > >> >> >> On 8 May 2015 at 21:32, Igor Stasenko <[email protected]> wrote: >> >>> >>> >>> On 8 May 2015 at 00:43, Nicolai Hess <[email protected]> wrote: >>> >>>> >>>> Some testers needed! >>>> >>>> I can not reproduce the BitBlt bug and I would like to get this right, >>>> so that surface pattern >>>> paints use the correct form dimension. >>>> >>>> Be sure, my fried, the bug is there, sitting in VM. >>> Bitblt implementation prereads a pixel from bitmap *before* checking the >>> loop bounds, meaning that it reads at least a single byte beyond the actual >>> contents of the bitmap. >>> It is not harmful in cases when bitmap is allocated in object memory >>> since VM memory design actually guarantees, that there are at least certain >>> amount of bytes in form of breathing space always available, so reading >>> single word past any allocated object is not hurts.. >>> But not in case, when bitmap residing in external heap.. because reading >>> beyond allocated space might cause segmentation fault.. and it was, until i >>> figured what was causing it and where the bug is. >>> >> > This mean it can happen every time we read form data from a surface plugin > - it is not only an issue for athens/cairo. > > Right, this is not cairo-only issue.. It just manifested itself when i was started using external surfaces allocated by cairo with bitblt. Which was causing occasional, irregular crashes time to time and i was quite lucky finding the cause of it.
> I will take a look at bitblt implementation. > > Thank you ! > > >> >>> >> The workaround, that i introduced was simply to tell Cairo to allocate >> surface 1 row taller and then use smaller height in bitblt operations, so >> it can never use the last row.. >> that, of course, going in conflict of using cairo for a patterns to fill >> things with bitmaps, which relying on surface's dimensions and using all >> its pixels.. >> :( >> >> hmm.. >> >>> >>> >>>> Prefered test setup: >>>> a (fresh) pharo image >>>> load bleeding edge from Bloc (because with bloc the whole (morphic) >>>> world is drawn with athens). >>>> change to watery theme ( because it makes some heavy use of form fills) >>>> verify that vertical scrollbars have this artifact (blank lines). >>>> load the attached code (this code reverts igors change for the 1 pixel >>>> extra height. >>>> >>>> please report back >>>> what platform windows/linux/mac 32/64 bit >>>> what pharo vm and image version. >>>> >>>> For me >>>> Windows 7 32 bit >>>> Win32 built on Apr 9 2015 21:05:04 Compiler: 4.6.2 >>>> Latest update: #50039 >>>> >>>> -> no segfault >>>> >>>> thanks in advance >>>> >>>> >>>> 2015-03-13 21:22 GMT+01:00 stepharo <[email protected]>: >>>> >>>>> I do not know. May be igor is reading this mailing-list but I doubt. >>>>> >>>>> >>>>> 2015-01-27 21:46 GMT+01:00 Nicolai Hess <[email protected]>: >>>>> >>>>> Anyone knows what this BitBlt bug is or was? >>>>>> 12818 <https://pharo.fogbugz.com/default.asp?12818> Last row missing >>>>>> 13236 <https://pharo.fogbugz.com/default.asp?13236> Fix 1 extra >>>>>> height for Cairo surface >>>>>> >>>>>> Because with the fix in 13236, it is not (easily) possible to make >>>>>> a repeating (vertical) pattern paint with 1 pixel height: >>>>>> 14813 <https://pharo.fogbugz.com/default.asp?14813> Wrong size for >>>>>> Athens surface pattern paint from a Form >>>>>> >>>>>> >>>>>> nicolai >>>>>> >>>>>> >>>>>> >>>>> BUMP >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko. >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > > -- Best regards, Igor Stasenko.
