[Date Prev][Date Next][Thread Prev][Thread Next][Thread Index]

Re: [XaraXtreme-dev] Mac Developer



On 18/08/06, Cristian Bortes <cristian.bortes@xxxxxxxxx> wrote:
Hi,
...
The problem appears to be in wxoil/grndrgn.cpp in the StaticPlotBitmap method.

My first thought is that on line 6303,

06303     wxAlphaPixelData BitmapData(Bitmap);

http://downloads.xara.com/opensource/doxygen/html/grndrgn_8cpp-source.html#l06303
, we obtain the wxAlphaPixelData, and promise not to look at the
RawData until the that object has gone out of scope. (RAII).

Do we break this promise on line 6311

06311     DWORD* pDBuffer = (DWORD*)Bitmap.GetRawData(BitmapData,32);

http://downloads.xara.com/opensource/doxygen/html/grndrgn_8cpp-source.html#l06312
?

If so, the assertion could be a True Bill: I am not sure why it is Mac
only (if that is so). Does the wxAlphaPixelData constructor only lock
the RawData on the Mac?

I am not sure quite what wxWidgets is doing. Why does it need both the
Bitmap and the BitmapData to enable us to plot into a bit map? If this
is wrong, why does it not disallow access (using this technique) when
the data are locked?

At line 6311 it needed an UngetRawData that
decreases rawAccesCount to a value of 0. This value is used by wxWidgets
to check whether an bmp object has rawAccess to the data. It appears
that after each use of GetRawData, UngetRawData must be called in order
maintain the level of the rawAccessCount.

I can easily see that every call to GetRawData() should be balanced by
a later call to UngetRawData(), but a moment ago you were asking us to
believe that it was correct to precede a call to GetRawData() with one
to UngetRawData(): this is much tougher row to hoe, I venture...

Ben.