Hi-DPI patches for 4.2

[Norbert Thiebaud]

On Mon, Mar 10, 2014 at 2:32 PM, Jan Holesovsky <kendy at collabora.com> wrote:
> Hi Norbert,
>
> Norbert Thiebaud píše v Po 10. 03. 2014 v 14:11 -0500:
>
>> > It is only 5 patches, as I have squashed the follow-up fixes into the
>> > appropriate patches, but other than that, it should bring us to the very
>> > same state that is in master.
>>
>> Not quite.. I had to add a bunch of #ifndef MACOSX around most of it
>> (and I may have missed some)
>> so that it does not mess-up Macosx retina display support.
>
> I was assured that those ifdefs are needed only when
>
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=0c9e4d9b223a0593686bee800484de3c23095d4f
>

I'll double check if that is indeed correct.
othoh if you have a 'staging' branch for these.. I may just try to
build _that_ and report.


>
> Having said that - why ifdef? ;-)  Why just not a function that does (or
> does not) scale according to the DPI scale level & if it is / is not
> OSX?

because 1/ that makes it clear that it is a undesirable hack (ifdef
stick out has ugly thing :-) )
2/ it may not be possible to address all these in one pass...
The problem I have not yet figured-out entirely is how properly deal
with size of the bitmap as expressed in 'point'
and size of he bitmap as expressed in 'pixel'....
and some bmp are 'resource' and other are 'generated at runtime (like
preview)... these pose a different set of problems.
3/ macosx magically deal with the scaling by default.. in fact _not_
making it do that for bitmap turned out to be something I have not
figured out yet...
/me has bitten the bullet and bought a couple of book about coca and
quartz programming.. with the hope to gain enough understanding of the
beast to be able to move vcl toward an api that would support some
control over these...

Norbert