Use TVirtualPadPainter interface for PS-based output#21485
Merged
linev merged 18 commits intoroot-project:masterfrom Mar 18, 2026
Merged
Use TVirtualPadPainter interface for PS-based output#21485linev merged 18 commits intoroot-project:masterfrom
linev merged 18 commits intoroot-project:masterfrom
Conversation
Test Results 22 files 22 suites 3d 4h 7m 20s ⏱️ Results for commit 0f1a1a0. ♻️ This comment has been updated with latest results. |
linev
force-pushed
the
pad_ps_painter
branch
3 times, most recently
from
73a4c5d to
c940e4d
Compare
linev
changed the title
silverweed
reviewed
Mar 6, 2026
couet
reviewed
Mar 10, 2026
linev
force-pushed
the
pad_ps_painter
branch
2 times, most recently
from
77e38b6 to
0f1a1a0
Compare
Instead gPad use provided pad pointer in the DrawFillAreaAux.
Idea to have exactly same interface as TPadPainter, but perform drawing on the TVirtualPS device. Add extra OnPad(pad) virtual method which specifies current pad which used for next commands
It replace pad painter by TPadPainterPS instance if gVirtualPS is detected. So PS painting can be done with pad painter API. At the end of Paint/PaintModified methods previous instance will be reset
Do not use gVirtualPS directly
Speical handling of TVirtualX in TPad::PaintBox. This method used for pad background painting and there difference between gVirtualX and gVirtualPS is significant. So keep two different handling of "native" (gVirtualX) and not-native kind of TPadPainter.
Excludes duplication of box boundary painting when fillstyle already 0. Appears in gmuiltierrors
So for both TVirtualX and TVirtualPS same code is used Slight difference in borders width calculation while before absolute pixel size was implemented in TVirtualPS
Create TSVG only after main canavas pad is selected with C->cd(); This important for size of created SVG image which ratio should correspond to ratio of pad pixel size
All four signature are changed
Need to provide special virtual method. Also supply default implementation
On the long run gVirtualPS should disappear
Similar to line, fill and text attributes while markers also used in pad painting
It is now not really necessary while attributes should be applied directly to pad painter
Now these methods act directly with actual pad painter to set attributes on device (gVirtualX or gVirtualPS) which is used. ModifyOn allows to work with pad pointer from user code
While new methods add to TAttLine and TAttFill
`NewPage()` used only PS to start page `IsCocoa()` let check if cocoa backend is used, invoved in several places `ResizeDrawable()` to change gVirtualX created pixmap Provide `TGLPadPainter::ClearDrawable()` while now pad painter API used in painting Now gVirtualPS usage in TPad minimized only to Print() method.
Only make sense when pad painter exists and has native funcitonality
couet
approved these changes
Mar 18, 2026
silverweed
reviewed
Mar 18, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Up to now painting code in
TPadis duplicated in many places.There is main part using
TPadPainter/gVirtualXAPI and part withgVirtualPS.In many aspects they are very similar and duplicate each other.
So try to provide
TPadPainterPSclass which fully covers usage of PS interface via pad painter.So one can fully remove use of gVirtualPS from painter code.
And if idea works out - replace in many other painters direct use of
gVirtualXby pad paintersFor the moment create
TPadPainterPSinstance whengVirtualPSdetected in theTPad::Paint()orTPad::PaintModified()methods. So one preserve existing functionality and support all existing use-cases.Later (in ROOT7) one can do it more strictly and fully remove
gVirtualPSglobal pointerand create proper PS/SVG/PDF instance in the
TPad::Print()method.Introduce
TAttLine::ModifyOn(TVirtualPad *pad)method which apply line attributes to the painter of the pad.So one can avoid usage of
gPadand directly specify target pad.TAttLine::Modify()just callsModifyOn(gPad).Same done for TAttFill, TAttMarker, TAttText. This shows direction of further changes - some TVirtualX functionality can be moved to pad painters so that several instances of pad painters can run in different threads and do not conflict with each other.
Extend
TVirtualPadPainterinterface to avoid direct use ofgVirtualXinterface as much as possible.For that one need to add several methods. Still in
TPad::ExecuteEvent()many places withgVirtualX,but it can be replaced easy later by pad painter methods.