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.
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. >
