[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Text shadows
From: |
Po Lu |
Subject: |
Re: Text shadows |
Date: |
Sun, 12 Mar 2023 18:33:38 +0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
Kai Ma <justksqsf@gmail.com> writes:
> On Mar 12, 2023, at 16:46, Po Lu <luangruo@yahoo.com> wrote:
>
> Theoretically, nothing. I targeted Cairo because (I think) it is the most
> popular option on GNU/Linux.
>
> Speaking of this specific implementation, gaussian_blur() relies on a
> specific Cairo image format ARGB32, (this assumption could be
> easily removed), and then it is used by ftcrfont_draw() to generate shadows.
>
> I don’t know whether non-Cairo builds (non-cairo X, win32) can/should use
> gaussian_blur() though, since I’m not familiar with them.
>
> Non-Cairo builds and Cairo builds alike should use the X Rendering
> Extension, where an arbitrary blur kernel is a standard picture filter.
> Cairo builds on X should as well.
>
> I agree XRender should be used for non-Cairo X builds (when XRender is
> available).
You can create a scratch Cairo surface backed by the drawable and
suitable picture format.
Temporary drawable and GC allocation is usually very fast in X servers
descending from the MIT sample server because they internally use many
different kinds of ``scratch pixmaps'' and ``scratch GCs'', but if you
worry about this kind of thing you can reuse the surface if you want
too.
Then, place a filter on that surface's picture and composite its
contents to FRAME_X_PICTURE (f).
Any code which involves Emacs writing to memory is unacceptable under X.
The reason is that the shared memory extension is not always available,
and is slower.
- Text shadows, Kai Ma, 2023/03/11
- Re: Text shadows, Kai Ma, 2023/03/11
- Re: Text shadows, Eli Zaretskii, 2023/03/12
- Re: Text shadows, Eli Zaretskii, 2023/03/12
- Re: Text shadows, Kai Ma, 2023/03/12
- Re: Text shadows, Eli Zaretskii, 2023/03/12
- Re: Text shadows, Kai Ma, 2023/03/12
- Re: Text shadows, Eli Zaretskii, 2023/03/12