Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
2do: should check whether it's better to directly assign the screen procs,
w/o any wrapping at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Wrapping ScreenRec's function pointers is problematic for many reasons, so
use the new window destructor hook instead.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Right now, extension specific window destruction procedures are implemented
by wrapping the ScreenRec's DestroyWindow() proc pointer: the extensions are
storing the original pointer in their private data and putting in their own one.
On each call, their proc restores the original one, calls it, and switches back
again. When multiple extensions doing so, they're forming a kind of daisy chain.
(the same is done for lots of other procs)
While that approach is looking nice and elegant on the drawing board, it's
complicated, dangerous like a chainsaw and makes debugging hard, leading to
pretty blurred API borders.
This commit introduces a simple approach for letting extension hook into the
window destruction safely, w/o having to care much about side effects with
the call chain. Extensions now can simply register their destructor proc
(and an opaque pointer) and get called back - w/o ever having to mess with
the ScreenRec's internal structures.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->ResizeWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This proc vector is optional (callers check for non-null) and neither fb nor
mi set it, so we can just assign our function directly. No need for wrapping.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
This wrapping function for Screen->CopyWindow() is does nothing more than
just call the original functions. So no need to keep wrapping it at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Both engines, GDI as well as DirectDraw, using the same screen init finish function,
so no need to keep indirection via per-engine callback pointer.
The winFinishScreenInitFB() can also be made static now.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
It does nothing more than just calling the original/wrapped function,
so we don't need that at all.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The whole struct is already allocated by calloc(), so no need to explicitly
zero-out individual fields.
Fixes: 479b2be4ba - Clear allocated RandR screen private structure
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Simplify reply payload preparation and sendout by using SwapShort()
and SwapLong() instead of WriteToClientSwapped() and callbacks.
This also allows even further simplifications by using generic macros
for the request send path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Harmonize it with all the other reply struct fields, so we can later
use generic macros for final preparation and writeout.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We can rely on everything being cleared. And usually even faster, as the
compiler can emit optimized instructions for clearing a whole block at once.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
We can rely on everything being cleared. And usually even faster, as the
compiler can emit optimized instructions for clearing a whole block at once.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Instead of arbitrary count of individual WriteToClient() calls on small
chunks, collect the whole payload in a buffer and write it out all at once.
This also makes possible to use generic macros for reply sending, as well
as further simplifications in the write-out path.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
WriteSwappedDataToClient() calls a callback on each single field.
We can have it easier and more efficient by just using SwapLongs()
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Using struct initializer for the reply header and only allocating the
payload on heap. This allows using generic macros for reply preparation
and send-out later.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Improve readability, move the declarations to where they're needed first
and get rid of extra individual assignments. In some cases this should also
allow the compiler to produce a bit more efficient code.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The struct is already zero'ed out by calloc(), so no need to additionally
clear individual fields.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to go indirectly through a vector table, since everything's fixed
anyways. It's not a pretty robust programming style: any changes need great
care, in order to not mix up things.
Replacing this by direct switch/case statement, which is using the defines
from the xrandr protocol headers. Also adding a little bit more protection
against subtle programming errors and reducing cognitive load (source size)
on understanding the code by using a tiny macro for deducing define name and
function name from the request's name.
This approach actually uncovered some subtle bug that had been waiting in
the dark for over 15 years.
As collateral benefit, getting a tiny bit better performance.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to go indirectly through a vector table, since everything's fixed
anyways. It's not a pretty robust programming style: any changes need great
care, in order to not mix up things.
Replacing this by direct switch/case statement, which is using the defines
from the xrandr protocol headers. Also adding a little bit more protection
against subtle programming errors and reducing cognitive load (source size)
on understanding the code by using a tiny macro for deducing define name and
function name from the request's name.
This approach actually uncovered some subtle bug that had been waiting in
the dark for over 15 years.
As collateral benefit, getting a tiny bit better performance.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
No need to go indirectly through an vector table. It's much clearer and
easier to understand when calling them directly. And a tiny bit performance
improvement as collateral benefit.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
The dispatcher functions are much more complex than they're usually are
(just switch/case statement). Bring them in line with the standard scheme
used in the Xserver, so further steps become easier.
It's also much cleaner to use the defines from proto headers instead of
raw numbers.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Allocate reply buffers on stack and put multiple fragments into one buffer,
in order to make it easier doing write out by generic macros, in subsequent
commits.
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
Make the code a bit easier to read by using initialization of the reply
structs, at the point of declaration. Most of them aren't written to later,
just passed into WriteReplyToClient(). Also dropping some useless zero
assignments (struct initializers automatically zero-out unmentioned fields).
Signed-off-by: Enrico Weigelt, metux IT consult <info@metux.net>
