[Libreoffice-bugs] [Bug 118029] crashtesting ooo24656-1.doc with --convert-to pdf

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=118029

Michael Meeks <michael.meeks at collabora.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Armin.Le.Grand at me.com

--- Comment #7 from Michael Meeks <michael.meeks at collabora.com> ---
Oh - wow ...

#13 0x00007fffef03fb0b in Bitmap::ReleaseAccess (pBitmapAccess=0x7fffb00010b0)
at /home/noel/libo/vcl/source/bitmap/bitmap.cxx:389
#14 0x00007fffeecde94a in vcl::ScopedBitmapAccess<BitmapReadAccess, Bitmap,
&Bitmap::AcquireReadAccess>::~ScopedBitmapAccess (this=0x7fffbfb8ba50)
    at /home/noel/libo/include/vcl/scopedbitmapaccess.hxx:85
#15 0x00007fffeed64c42 in BitmapEx::GetPixelColor (this=0x7fffb00015e8, nX=116,
nY=48) at /home/noel/libo/vcl/source/gdi/bitmapex.cxx:759
#16 0x00007fffe8d1bf92 in
drawinglayer::texture::GeoTexSvxBitmapEx::modifyBColor (this=0x7fffb00015e0,
rUV=..., rBColor=..., rfOpacity=@0x7fffbfb8bd30: 1)
    at /home/noel/libo/drawinglayer/source/texture/texture3d.cxx:125
#17 0x00007fffe8d1c848 in 

Looks like a disaster not just from a threading perspective - but a performance
perspective too =) Creating and destroying this guy:

        Bitmap::ScopedReadAccess pReadAccess( aTestBitmap );

per-pixel can (IIRC) result in a DMA directly to GPU memory and all sorts of
horrible slowness (I forget if we cache on the CPU the copy we get back there).
Either way - that looks really 'orrible.

I'm rather surprised that we're threading the Bitmap access in the first
instance TBH - and then doing manual pixel bashing serially on the CPU while
threaded rather than in a shader in unbelievable parallel (hundreds wide) on
the GPU - is also a curious choice but ... ;-)

It is far from clear to me that doing tons of atomic references and making
'mapmode thread safe' ;-) [ if that is even the plan ] is the right way to do
threading; sounds impossibly granular to me =)

So - what gives ? this looks quite far from ideal to me =)

--- Comment #8 from Michael Meeks <michael.meeks at collabora.com> ---
Oh - wow ...

#13 0x00007fffef03fb0b in Bitmap::ReleaseAccess (pBitmapAccess=0x7fffb00010b0)
at /home/noel/libo/vcl/source/bitmap/bitmap.cxx:389
#14 0x00007fffeecde94a in vcl::ScopedBitmapAccess<BitmapReadAccess, Bitmap,
&Bitmap::AcquireReadAccess>::~ScopedBitmapAccess (this=0x7fffbfb8ba50)
    at /home/noel/libo/include/vcl/scopedbitmapaccess.hxx:85
#15 0x00007fffeed64c42 in BitmapEx::GetPixelColor (this=0x7fffb00015e8, nX=116,
nY=48) at /home/noel/libo/vcl/source/gdi/bitmapex.cxx:759
#16 0x00007fffe8d1bf92 in
drawinglayer::texture::GeoTexSvxBitmapEx::modifyBColor (this=0x7fffb00015e0,
rUV=..., rBColor=..., rfOpacity=@0x7fffbfb8bd30: 1)
    at /home/noel/libo/drawinglayer/source/texture/texture3d.cxx:125
#17 0x00007fffe8d1c848 in 

Looks like a disaster not just from a threading perspective - but a performance
perspective too =) Creating and destroying this guy:

        Bitmap::ScopedReadAccess pReadAccess( aTestBitmap );

per-pixel can (IIRC) result in a DMA directly to GPU memory and all sorts of
horrible slowness (I forget if we cache on the CPU the copy we get back there).
Either way - that looks really 'orrible.

I'm rather surprised that we're threading the Bitmap access in the first
instance TBH - and then doing manual pixel bashing serially on the CPU while
threaded rather than in a shader in unbelievable parallel (hundreds wide) on
the GPU - is also a curious choice but ... ;-)

It is far from clear to me that doing tons of atomic references and making
'mapmode thread safe' ;-) [ if that is even the plan ] is the right way to do
threading; sounds impossibly granular to me =)

So - what gives ? this looks quite far from ideal to me =)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20180606/d7529a21/attachment-0001.html>