Issue 122418 - Fail to show color or display incorrectly in Color listboxes
Fail to show color or display incorrectly in Color listboxes
Status: RESOLVED FIXED
Product: General
Classification: Code
Component: ui
4.0.0-dev
Mac Mac OSX, 10.8
: P2 major (vote)
: 4.0.0
Assigned To: Armin Le Grand
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-05-30 03:11 UTC by liuping
Modified: 2013-07-11 08:19 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation on: ---
Developer Difficulty: ---


Attachments
Capture (159.03 KB, image/png)
2013-05-30 03:11 UTC, liuping
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description liuping 2013-05-30 03:11:39 UTC
Created attachment 80746 [details]
Capture

Build Version: AOO400ml(Build:9700) -Rev 14846779

1. New a documnets or presentation or spreadsheet
2. Input and select some text ,then select "character" in context menu 
3. Switch "Font Effects" tab , select Overlining is Single ,
4. Check "Overline color" drop down menu

Issue:
Fail to show color in color palette

The similiar happen on such as Underline color and Shape Area Fill Color  


Refer capture in attachment
Comment 1 Armin Le Grand 2013-05-30 13:49:01 UTC
ALG: Seen that, hdu and me are on it. Looks as if the VirtualDevices used to prepare the previews on mac need some kind of flush() before getting the preview bitmap from them using GetBitmap(). Adding hdu to cc..
Comment 2 Armin Le Grand 2013-06-04 08:56:58 UTC
ALG: Grepping...
Comment 3 Armin Le Grand 2013-06-04 13:52:15 UTC
ALG: Working through AquaSalGraphics/AquaSalBitmap and Mac CGLayer/CGContext stuff, Cocoa windows and Quartz contexts (Layers and Contexts). Looks as if Contexts can be flushed, but Layers cannot.
The basic problem is that when creating a temporary Bitmap from an OutDev, drawing to the bitmap and then drawing pack the bitmap. the initial copying step does not really copy the data. Experimenting with flushing...
Comment 4 Armin Le Grand 2013-06-04 17:09:54 UTC
ALG: I ahve prepared some 'workaround' which avoid fetching the Bitmap from a OutputDevice, but uses BitmapEx mechanisms to achieve the same. It does not solve the basic problem, but avoids it, thus will prepare the way for AOO4.0. Doing some more checks...
Comment 5 Armin Le Grand 2013-06-05 10:58:23 UTC
ALG: Did some more experiments on mac, but I could not track down the reason that GetBitmap fails. Doing one more, but will commit the workaround soon (of course with the workaround, it is no more trackable).
Comment 6 Armin Le Grand 2013-06-05 11:28:57 UTC
ALG: Checked if GetBitmap on mac is used at all when source OutDev is a Window, added code, found no single case after setting a breakpoint there and playing around with the office a while (with the workaround applied).

This is in principle good news, read-access to windows is not guaranteed on all systems (and the trend is that this is less supported on more modern systems). Maybe an alternative would be to not try to support these problematic cases, but assert them so that when developing developers will stumble over this guaranteed and know to not use it?

Now back-adding one of the error cases to continue tracking...
Comment 7 hdu@apache.org 2013-06-05 12:44:22 UTC
(In reply to Armin Le Grand from comment #6)
> This is in principle good news, read-access to windows is not guaranteed on
> all systems (and the trend is that this is less supported on more modern
> systems). Maybe an alternative would be to not try to support these
> problematic cases, but assert them so that when developing developers will
> stumble over this guaranteed and know to not use it?

Agreed: We should assert such cases where assumptions about the system have been obsoleted, so a developer is alerted if the case happens and can avoid them. XOR operations on graphics will fall into the same category once the remaining current usages have been replaced.
Comment 8 Armin Le Grand 2013-06-05 14:53:23 UTC
ALG: Preparing to commit woraround.

Tried to assert when GetBitmap() source is a window, but this happens pretty often (hover over the toolbar UI), so this is not an option, sorry. It is needed and should be repaired.
Note: The place to add test code to get the non-working scenario back is svtools/source/control/ctrlbox.cxx:244 ff (ask me).
Comment 9 Armin Le Grand 2013-06-05 14:56:38 UTC
ALG: Preparing updated mac build to check...
Comment 10 SVN Robot 2013-06-05 15:05:35 UTC
"alg" committed SVN revision 1489899 into trunk:
i122418 Added workaround to not use GetBitmap on windows
Comment 11 Armin Le Grand 2013-06-05 17:25:07 UTC
ALG: Okay, test build done, works as expected. Setting to fixed for 4.0