Skip to content

Use TVirtualPadPainter interface for PS-based output#21485

Open
linev wants to merge 19 commits intoroot-project:masterfrom
linev:pad_ps_painter
Open

Use TVirtualPadPainter interface for PS-based output#21485
linev wants to merge 19 commits intoroot-project:masterfrom
linev:pad_ps_painter

Conversation

@linev
Copy link
Member

@linev linev commented Mar 4, 2026

Up to now painting code in TPad is duplicated in many places.
There is main part using TPadPainter/gVirtualX API and part with gVirtualPS.
In many aspects they are very similar and duplicate each other.
So try to provide TPadPainterPS class 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 gVirtualX by pad painters

For the moment create TPadPainterPS instance when gVirtualPS detected in the TPad::Paint() or TPad::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 gVirtualPS global pointer
and 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 gPad and directly specify target pad. TAttLine::Modify() just calls ModifyOn(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 TVirtualPadPainter interface to avoid direct use of gVirtualX interface as much as possible.
For that one need to add several methods. Still in TPad::ExecuteEvent() many places with gVirtualX,
but it can be replaced easy later by pad painter methods.

@linev linev self-assigned this Mar 4, 2026
@linev linev marked this pull request as draft March 4, 2026 11:11
@github-actions
Copy link

github-actions bot commented Mar 4, 2026

Test Results

    22 files      22 suites   3d 4h 51m 18s ⏱️
 3 831 tests  3 830 ✅ 1 💤 0 ❌
76 643 runs  76 634 ✅ 9 💤 0 ❌

Results for commit b29d5d4.

♻️ This comment has been updated with latest results.

@linev linev force-pushed the pad_ps_painter branch 3 times, most recently from 73a4c5d to c940e4d Compare March 6, 2026 07:03
@linev linev changed the title [draft] use pad painter for PS output Use TVirtualPadPainter interface for PS-based output Mar 6, 2026
@linev linev marked this pull request as ready for review March 6, 2026 09:19
virtual void DrawPolyLine(Int_t n, const Float_t *x, const Float_t *y) = 0;
virtual void DrawPolyLineNDC(Int_t n, const Double_t *u, const Double_t *v) = 0;

virtual void DrawSegments(Int_t n, const Double_t *x, const Double_t *y);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are these parameters not const anymore?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because in these methods allowed to change content of the buffers.

These methods were introduced last week and used up to now only internally - and only with temporary buffers anyway.

linev added 15 commits March 6, 2026 13:26
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
While now painting done via TVirtualPadPainter instance,
attributes should be derived from current TWebPS instance

Also properly use web painting when master TWebPS is used
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
linev added 4 commits March 6, 2026 13:28
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants