[cocoa] use window context for graphics#21705
Open
linev wants to merge 21 commits intoroot-project:masterfrom
Open
[cocoa] use window context for graphics#21705linev wants to merge 21 commits intoroot-project:masterfrom
linev wants to merge 21 commits intoroot-project:masterfrom
Conversation
Test Results 22 files 22 suites 3d 9h 10m 4s ⏱️ For more details on these failures, see this check. Results for commit ebbbd30. ♻️ This comment has been updated with latest results. |
linev
force-pushed
the
cocoa_wctxt
branch
2 times, most recently
from
5ac0f6b to
fca1901
Compare
linev
changed the title
It is main window handle to provide new functionality
It is just pointer to correspondent attributes instance which can be used to store current set attributes Provide implementation in QuartWindow, QuartzPixmap and QuartzImage
These should be at the end the only methods for setting attributes Also implement internal attributes getter methods which later can be moved in base TVirtualX class
Such approach can be done in the future just in base TVirtualX class when all implementations support new API
For that intoduce setDrawMode interface for drawable And implement only for relevant class
Using WinContext_t which delivers own attributes
Attributes handling similar to DrawBoxW
These are last methods which are important for graphics drawing
There is now alternative method used together with WinContext_t argument
Remaining place is text drawing
So potentially one can have independent handling
Simplify internal handling of draw mode
While line/rect XOR drawing performed within window context argument anyway - manage such buffer in the window. And in TGCocoa::Update just iterate over existing widgets and flush XOR operations if exists.
So this view collects all commands and marked as need to be displayed.
No need central XOR buffer and many service methods.
One need to call DrawPolyLineW otherwise context will be lost in default TVirtualX implementation
In this case TTF is used. And align is stored now in native ROOT format like 22 or 13
Extend Quartz::TextLine. While it is private class, one can change API
No need to fallback to gVirtualX while this is private interface
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
1 participant
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.
Like for
TGX11, provide API methods to draw graphics using window context.By large extent internal organization was done already so that all graphical operations were handled independently for different windows. Like GC (graphics context) objects were organized per window.
The only big change there - handling of
TAtt...classes to be able configure attributes fully independent for different canvases.Important change which need to be tested is changed XOR operations - like for crosshair cursor.
Now XOR operations accumulated independent for each widget. And display for these operations performed fully asynchronousely using setNeedsDisplay functionality. Before all such operations were accumulated in global
fXorOpsbuffer and redistributed to individual widgets insidegVirtualX->Update(3)call. Now all this not necessary - but need to be tested.