[ ] clean debug log, set not DPI by default (see config.h)
[ ] create a new event change_scale(float new_scale) / change_dpi(int new_dpi)
This compile in Ubuntu (in GitHub actions with GCC 13; and in WSL2 with GCC11 using Eclipse/cmake)
In Windows 10 (MSVC2022 and MinGW with GCC 13) - run OK by dpi 96, and ALREADY solve some problems by dpi change !!
But there is a lot to do: see #698, in To Do
[ ] graphics keep the target dpi: every single graphics need to .set_dpi(new_dpi) after a windows change the dpi and before refresh !!
[ ] implement a .change_dpi(new_dpi) in widget, widget_base, widget_object and basic_window that apply .set_dpi(new_dpi) to every graphics ??
[ ] In the implementation of graphics in functions bitblt, paste and stretch check that the src and dst have the same target dpi to decide to use a 'paste' or to do instead 'stretch' before.
[ ] bitblt,
[ ] paste and
[ ] stretch
[ ] check that every use of graphics all around nana set the correct target dpi before drawing and 'paste' and that only US coordinate are passed to it. (take graphics from api::window_graphics(window wd) ? or take the dpi of wd and pass to the new graphics)
[x] animation (set by user? make it clear in api docs?), but animation::impl create one more : framegraph
[x] drawing.draw (set by user? make it clear in api docs?)
[x] drawer.draw (set by user? make it clear in api docs?) - implement drawing::draw
[ ] nana::effects / bground_interface
[ ] nana::element / graph_reference in element_abstract, facade, cite_bground, bground
[ ] place in splitter_renderer
[x] drawer_trigger in base drawer keep a graphics.
[ ] paint::graphics temp_graph; in api::content_extent
[ ] check that in every use of pixel_buffer all around nana only System-side (SS) coordinate are passed to it. If this is not possible or desired, use only US (don't mix US and SS !!) and do a stretch at the end, instead of paste.
BEFORE merge this (please, set IGNORE whitespaces !! those are just for doxy-docs and readability ):
change_scale(float new_scale)/change_dpi(int new_dpi)This compile in Ubuntu (in GitHub actions with GCC 13; and in WSL2 with GCC11 using Eclipse/cmake)
In Windows 10 (MSVC2022 and MinGW with GCC 13) - run OK by dpi 96, and ALREADY solve some problems by dpi change !! But there is a lot to do: see #698, in To Do
graphicskeep the target dpi: every singlegraphicsneed to.set_dpi(new_dpi)after a windows change the dpi and before refresh !!.change_dpi(new_dpi)inwidget,widget_base,widget_objectandbasic_windowthat apply.set_dpi(new_dpi)to everygraphics??bitblt,pasteandstretchcheck that the src and dst have the same target dpi to decide to use a 'paste' or to do instead 'stretch' before.bitblt,pasteandstretchgraphicsall around nana set the correct target dpi before drawing and 'paste' and that only US coordinate are passed to it. (takegraphicsfromapi::window_graphics(window wd)? or take the dpi of wd and pass to the newgraphics)animation(set by user? make it clear in api docs?), butanimation::implcreate one more :framegraphdrawing.draw(set by user? make it clear in api docs?)drawer.draw(set by user? make it clear in api docs?) - implementdrawing::drawnana::effects/bground_interfacenana::element/graph_referenceinelement_abstract,facade,cite_bground,bgroundplaceinsplitter_rendererdrawer_triggerin basedrawerkeep agraphics.api::copy_transparent_background,glass_buffernana::element::bground::draw_graphnana::paint::graphics nana::element::bground::draw_graph::graphnana::paint::graphics nana::widgets::skeletons::text_editor::implementation::inner_counterpart::buffermsgboxico_ X11nana::paint::graphics nana::place::implement::div_dockpane::indicator_rep::graphpixel_bufferall around nana only System-side (SS) coordinate are passed to it. If this is not possible or desired, use only US (don't mix US and SS !!) and do a stretch at the end, instead of paste.701, #702 and #698 may help to get an idea.