Use separate pixmaps for each edge of a container #4382
Conversation
This file contains 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
A "multi surface" (I am bad at naming things) consists of multiple surface. Imagine you have a desk (the thing made out of wood) and you arrange multiple sheets of papers on it. Each paper has a position and a size. You can then "draw to the desk" and some of your drawing will end up on some of the papers. This is exactly what I mean with a "multi surface": It consists of up to four surface_t instances. Each of them has a position which is its offset from (0, 0). When drawing to the "multi surface", the drawing is done on each of the contained surfaces, but with the offset applied. All of the functions from draw_util are also available on "multi surfaces". A bit of a special case is multi_surface_copy_surface(). Compared to draw_util_copy_surface(), there is an extra "fill_color" argument. All areas that are not covered by any of the surfaces will be filled with this fill color. Think of it as the background color of the desk in my introductory example above (and also: No drawing to the desk is possible; it always keeps its background color). Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Uli Schlachter <psychon@znc.in>
This switches Con::frame_buffer to be a multi_surface_t instead of a surface_t. All drawing code is accordingly updated. The multi surface still contains only one surface, so this commit "should not actually change anything". Splitting up the underlying pixmap into multiple smaller ones is left for a future commit. Signed-off-by: Uli Schlachter <psychon@znc.in>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Here is my current attempt at fixing #3479.
It does not work.
x_get_border_rectangles()callscon_adjacent_borders()which follows aNULLpointer and crashes. I "fixed" that with a NULL pointer check, but now this function is giving me all empty rectangles for the borders:(No, I did not yet look at where that segfault comes from; yes, I can open a window, but it ends up with all-black frames)
So, this (draft) PR is just to document my current state and to ask:
How do I get the necessary size of the border pixmaps?
It seems like
con->window_rectis the geometry of the "inner window" andcon->rectis the geometry of the outer window (so I get width and height from this). Is this correct? Is there some existing helper that allows me to turn this into up to four rectangles describing the "area not covered by the inner window"? Isx_get_border_rectanges()meant for something else?