> Your code works well on my PC with a 24" monitor at 1920x1080 and DPI
> manually adjusted to 144.
Forgot to add that the dpi configuration panel on windows7 works as a percent
over default, that is, to set it to 144ppi I actually chose 150% increase and
that results on 96*1.5=144
_
Your code works well on my PC with a 24" monitor at 1920x1080 and DPI manually
adjusted to 144. Here is the output of both codepaths:
D:\home\dpi>test
set_show_dpi(81): size=14, scrollbar_size=16
set_show_dpi(95): size=14, scrollbar_size=16
Screen 0 ( 0, 0,1280, 695) res. is 96.000 x 96.00
> It's in 1.3.0RC3: Fl::screen_dpi(float &hor, float &vert, int =
> screenIndex);
>
> I hope it helps, although I am concerned that the OS routines we use =
> seem to return 72 pretty much all the time... .
>
>
@Matthias Melcher:
No, it doesnt work on Windows Vista and above due to the built in m
While in theory you can use Fl::set_boxtype() to retheme your app you will be
very limited.
Some months ago I attempted a cairo-drawn aqua-like theme by dynamically
generating images to be tiled by the different boxtypes and eventually cache
them.
I found several problems but the major one was
Thankyou for your help.
I will be offline for a day or so but I will study your code when I´m back.
> Also, note that with fltk-1.3 on OSX, at present, reading back from
> the offscreen can be a little bit hosed. Works fine on X11 and win32
> though, and fltk-1.1 works fine, and AFAIK fltk2 works
Hi,
is it possible to draw the contents of a widget hierarchy ito a memory buffer?
Grabbing screen contents after normal redraw is not good enough due to
potential overlapping windows over the area.
My goal is to implement something like this (and other effects):
http://vimeo.com/moogaloop.swf?c
6 matches
Mail list logo
