Nabble - Free Desktop - Cairo - General

_cairo_scaled_font_is_frozen(scaled_font) assertion failure with freetype on win32-printing surface

2009-12-01T03:00:15Z

Hi,

Could someone explain the basic workflow for text rendering with scaled fonts?

Currently, I have two faces in TrueType files. I load them using Freetype, pass to cairo_ft_font_face_create_for_ft_face(), then assign the source FT_Face-s as user data with FT_Done_Face as destroy function, create several instances of scaled font for each of the faces (of different size) and do the rendering.
I works fine for surfaces but the win32-printing one. In the latter case an assertion fails with _cairo_scaled_font_is_frozen(scaled_font) expression. I've tried locking the font each time before setting it, but it seems to make no different. Could you explain what's wrong here and how should one use the font locking mechnism?

Thanks in advance,
Mikhail.
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

pixman_fill() on MMX/SSE

2009-12-01T00:54:20Z

Hey,

Attached is a patch that makes pixman_fill() work with non-32 bpp. The
MMX and SSE code paths expect the xor value to be expanded to 32bit
while both the NEON and the fast-path implementations do not. And the
callers don't expand the value either.
So I'm very sure the fix is straight-forward and doesn't break
anything, but the checks that I remove might have been there for a
reason.
So it's your time to speak up now If you know why. And if , I'm just
gonna commit it in a few days.

Benjamin

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

diff (2K) Download Attachment

Re: Objections to changing most text tests to use the internal font?

2009-11-30T23:50:31Z

Behdad Esfahbod wrote:
> What I suggest is:
>
> - Include one Type1, one TrueType, and one bitmap font in boilerplate/.
> Like we do with surface, have boilerplate/test run the text tests against all of:
>
> - Twin font
> - FreeType with Type1 font
> - FreeType with TrueType font
> - FreeType with bitmap font

I started some work last year to included a TrueType, OpenType/CFF, and
Type 1 font for testing the subsetting:

http://cgit.freedesktop.org/~ajohnson/cairo/log/?h=font-subset-test

Please review this branch and see what you think of the boilerplate
changes for testing the subsetting.

Commit 9d0733bb adds the fonts to the test suite. It is based the Nimbus
Sans L Regular font.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Objections to changing most text tests to use the internal font?

2009-11-30T18:54:46Z

On 11/30/2009 08:09 PM, Travis Griggs wrote:
> On Nov 30, 2009, at 4:30 PM, Behdad Esfahbod wrote:
>
>> As for fonts to ship, WallaWalla from Garrett should do the job:

> There is a font called WallaWalla???? I can't tell you how totally
> cool I think that is. Thanks for sharing.

Here it is:
http://linuxart.com/log/archives/2008/08/29/hack-week-wrap-up/

The other font I was thinking of is:
http://jimmac.musichall.cz/log/?p=441

They are like 40k each.

behdad
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Objections to changing most text tests to use the internal font?

2009-11-30T17:09:35Z

On Nov 30, 2009, at 4:30 PM, Behdad Esfahbod wrote:

> As for fonts to ship, WallaWalla from Garrett should do the job:

There is a font called WallaWalla???? I can't tell you how totally
cool I think that is. Thanks for sharing.

--
Travis Griggs (who lives in Walla Walla Washington)
Objologist
"The best way to know you have a mind is to change it" -Judge Pierre
Leval

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Objections to changing most text tests to use the internal font?

2009-11-30T16:30:58Z

I'm fine with that except that it wouldn't test any of the cairo-ft backend or
any of the Type1/TrueType/Type3 etc code. Which is fine. We need to add
separate tests for those.

So, my recommendation is to switch all the "cairo_select_font_face()" tests to
twin. That leaves all the ft-*.c and bitmap-font.c tests. Those currently
use Fontconfig API. We should instead break them down to a bunch, such that:

- They test the cairo Fontconfig API

- Separate tests for the cairo FreeType API

- Tests for the different subsetters

What I suggest is:

- Include one Type1, one TrueType, and one bitmap font in boilerplate/.
Like we do with surface, have boilerplate/test run the text tests against all of:

- Twin font
- FreeType with Type1 font
- FreeType with TrueType font
- FreeType with bitmap font

When we add cairo_font_face_create() later, we can extend that to all native
backends.

As for fonts to ship, WallaWalla from Garrett should do the job:

http://ux.suse.de/~garrett/public/wallawalla/0.1/WallaWalla.sfd

We can use fontforge to create TrueType and Type1 variants.

Or use that for TrueType, and another face for Type1 so we can distinguish
them easily.

Anyway, I know this is a bit more than you asked for, but something we should
have done long ago.

Cheers,
behdad

PS. I expect you'd see bugs with user-font not dealing with font-matrix
offsets correctly...

On 11/28/2009 10:55 AM, M Joonas Pihlaja wrote:

>
> Hey,
>
> Does anyone have any objcetions to me shifting most of the text test
> cases to use the Twin font?
>
> Until recently a lot of the text tests have been failing for me due to
> mismatches between whatever font which is called "Bitstream Vera" on
> my system and the system used to generate the ref images. A few
> months ago the stars have aligned for me and now the majority of them
> pass suddenly, so presumably they're now failing with other Bitstream
> Veras.
>
> Cheers,
>
> Joonas

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: how to increase a new operator in cairo

2009-11-30T07:04:39Z

On Mon, 30 Nov 2009, Liang Wang wrote:

> We want to increase a new operator for ROP operation "AND".
> Could you tell me how to do it.

Does IN or DEST_IN not work for your needs? How do you define AND
anyway?

To add another operator you'd first need to get it into pixman, so
have a look at how pixman implements its operators. Adding support in
cairo after pixman supports it is only a little bit of code after
that.

Cheers,

Joonas
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

how to increase a new operator in cairo

2009-11-30T05:50:20Z

We want to increase a new operator for ROP operation "AND".

Could you tell me how to do it.

Thank you very much.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: freetype on windows

2009-11-29T10:04:02Z

> If that's the case, should it not be "fixed" in the source?

Sure. File a bug please.

--tml
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Would like to submit some patches for Haiku (and BeOS) soon

2009-11-29T09:22:12Z

Hey there,

My name is Urias McCullough (IRC: umccullough) and I just wanted to
let the list know that I would like to submit a few Haiku-related
patches in the near future.

About a year ago, a couple people in the Haiku community (including
myself) started seeing what it would take to get Cairo *building* on
Haiku, and it turned out to be pretty minor. Since then, things have
changed again, so the old patches no longer work anyway.

To simplify things, I'd like to get some of the patches into the
master so we can avoid having to re-patch everything again and again.

Most of the patches are small and simple - but I'll probably submit
them in logical pieces for individual review and commit to get things
going.

Would this mailing list be the best place to submit patches?

Disclaimer: I'm not much of a C/C++ dev, so while I can tweak little
things here and there, I will probably struggle with larger changes.
For some of those I will try to find better developers from the Haiku
community to assist.

Thanks,

Urias McCullough
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Storing vector information for drawing later

2009-11-29T08:34:33Z

Emmanuel Pacaud wrote:
> Hi,
>
>
> The current development snapshot (1.9.2) exports the cairo-meta-surface,
> that can be used for vector operation recording.
>
> It will be renamed to cairo-recording-surface in the next stable version
> (which is already done in cairo git master branch)
>

Hi Emmanuel

Thanks for the information. For now, I am trying to get Cairo 1.8.8
built for Windows CE. Once I manage that, I'll keep a lookout on the
1.9.2 snapshot to look at how the cairo-recording-surface works.

Cheers,
Mohit.
11/30/2009 | 12:34 AM.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Calling on subsystem maintainers to get ready to check their backends.

2009-11-29T08:30:46Z

Hey all,

This is a heads up for anyone who has an interest in the
"experimental" cairo backends or non-VAX platforms. We're pushing
towards a 1.10 cairo release in the not totally distant future, so if
you have a favourite backend please get check that your backend still
works. There's a big change in Chris' pipeline which affects how the
backends are structured cooking here:

http://cgit.freedesktop.org/~ickle/cairo/commit/?h=wip/compositor

It's likely a good idea to wait until that gets merged into git
master, but after that would be a great time to shake any bugs out. :)

Cheers,

Joonas
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: freetype on windows

2009-11-29T07:24:50Z

Kozhevnikov Mikhail wrote:
> Seems to work fine without it. Thank you!
> Didn't think of it this way :)
>
> Cheers,
> Mikhail.
>
If that's the case, should it not be "fixed" in the source?

Cheers,
Mohit.
11/29/2009 | 11:24 PM.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: freetype on windows

2009-11-29T04:33:02Z

Seems to work fine without it. Thank you!
Didn't think of it this way :)

Cheers,
Mikhail.

28.11.09, 00:00, "Tor Lillqvist" :

> > Dingo is built with MSVC, while fontconfig.h requires unistd.h.
>
> Does it really "require" it? What happens if you just remove that
> #include ? Quickly glancing, I don't see any immediate
> reason why would need to include .
>
> --tml
>
>

--
Здесь спама нет http://mail.yandex.ru/nospam/sign
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Video Hackfest conclusions

2009-11-28T11:29:36Z

On Tuesday 24 November 2009, Benjamin Otte wrote:

> Hi,
>
> As you may be aware, we held a video hackfest last week in Barcelona.
> Developers met to discuss how best to improve GPU support for video
> applications. See http://gstreamer.freedesktop.org/wiki/VideoHackfest
> for more details. In particular, you might be interested in the notes
> some people took while the hackfest was going on. These can be found
> at http://gstreamer.freedesktop.org/wiki/VideoHackfest/Notes
>
> What follows is the results we arrived at after the hackfest. They are
> taken from http://gstreamer.freedesktop.org/wiki/VideoHackfest/Conclusions
> but certainly deserve wide circulation. We're interested in any
> comments (or questions) you might have about them, so please don't
> heistate to reply.
>
> If you do reply, please make sure to reduce the recipient list
> appropriately.

[...]

> == YUV in pixman ==
> It has been a goal for a while to make video a first-class citizen in
> the image stack. A concrete API proposal on how to integrate video
> into pixman was reached and reviewed.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/YCbCr_Formats
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/pixman
> Actions:
> * GStreamer developers to provide a specification of important YUV formats
> * Write implementation
>
> == YUV in Cairo ==
> To make it easy for applications to use these different formats, the
> Cairo API needs to be extended to allow them. A proposal does exist
> and has been reviewed, details need to be finalized.
> Links:
> * http://gstreamer.freedesktop.org/wiki/VideoHackfest/Cairo
> Actions:
> * Finalize proposal
> * Write implementation

I would like to have some clarification regarding forcing BILINEAR filter for
nonscaled YCbCr images.

What happens if some YCbCr image is used as both source and destination if we
want to draw some RGB stuff on top of video frame? In this case the operation
will be split into fetching YCbCr data into temporary scanline buffer (and
converting it to a8r8g8b8 format), doing the operation and writing data back,
converting it to YCbCr. For this kind of operation, any distortions in the
original image are probaby not desired. A test can involve trying to do OVER
compositing operation with fully transparent RGB source and YCbCr as
the destination. Optimistically, the destination image should not change at
all. But in reality, some of the pixels have to be clamped to [0, 255] range
when converting to RGB. So the requirement can be relaxed to requiring
YCbCr -> RGB -> YCbCr roundtrip to only be allowed to modify the values which
are clamped during this conversion. It can be treated somewhat similar to
handling top 8 bits in x8r8g8b8 format. Some different YCbCr pixel values map
to the same a8r8g8b8 value, but so do x8r8g8b8 pixels.

Using bilinear filter on YCbCr -> RGB -> YCbCr roundtrip would introduce some
blur unless I'm mistaken. But this filter may still be a good idea when
generating a final RGB picture. BTW, introducing a dithering filter for doing
final conversion into r5g6b5 format may be a good idea too.

--
Best regards,
Siarhei Siamashka
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Objections to changing most text tests to use the internal font?

2009-11-28T07:55:54Z

Hey,

Does anyone have any objcetions to me shifting most of the text test
cases to use the Twin font?

Until recently a lot of the text tests have been failing for me due to
mismatches between whatever font which is called "Bitstream Vera" on
my system and the system used to generate the ref images. A few
months ago the stars have aligned for me and now the majority of them
pass suddenly, so presumably they're now failing with other Bitstream
Veras.

Cheers,

Joonas
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: freetype on windows

2009-11-27T14:00:45Z

> Dingo is built with MSVC, while fontconfig.h requires unistd.h.

Does it really "require" it? What happens if you just remove that
#include <unistd.h>? Quickly glancing, I don't see any immediate
reason why <fontconfig.h> would need to include <unistd.h>.

--tml
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: freetype on windows

2009-11-27T09:04:17Z

I built all dependencies with MSVC by this method, and all
dependencies can be found at this repository. You can check the
history to see what I did.

Best Regards

Shixin Zeng

2009/11/27 Kozhevnikov Mikhail <mikhailkozhevnikov@...>:

> Hi Shixin,
>
> Looks interesting. Do you use some existing set of libraries that mimic the UNIX enviroment? Or do you implement it all on your own?
>
> Mikhail
>
> 27.11.09, 10:25, "Shixin Zeng" <zeng.shixin@...>:
>
>> I have a repository with an ambition to build as many gnome apps on
>> windows with MSVC as possible, where includes freetype. It's based on
>> scons and still in progress, and I'm just building some gnome related
>> libraries.
>>
>> The repository is located at:http://github.com/zsx/freetype2
>> The instructions:http://code.google.com/p/gnome4win/wiki/GetStarted
>>
>> Best Regards
>>
>> Shixin Zeng
>>
>>
>>
>> On Fri, Nov 27, 2009 at 10:09 AM, Kozhevnikov Mikhail
>> wrote:
>> > Hi,
>> >
>> > I've got a bug report for Dingo on Windows having some fonts displayed incorrectly. It appears to be again the same one mentioned here http://lists.cairographics.org/archives/cairo/2009-October/018321.html.
>> > I thought of using Freetype font backend to fix this. However, there's a problem as Dingo is built with MSVC, while fontconfig.h requires unistd.h.
>> >
>> > Has anyone tried using freetype on Windows with MSVC?
>> >
>> > Cheers,
>> > Mikhail.
>> >
>> > --
>> > cairo mailing list
>> > cairo@...
>> > http://lists.cairographics.org/mailman/listinfo/cairo
>> >
>>
>>
>
> --
> Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign
>

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: [PATCH] pixman: high qualtiy downscaling

2009-11-27T08:51:47Z

Soeren Sandmann wrote:
> Maybe that is CAIRO_FILTER_GOOD, but that would conflate interpolatino
> and sampling, which would bug me. Another possibility is that cairo
> simply offers
>
> CAIRO_RESAMPLE_FAST
> CAIRO_RESAMPLE_GOOD
> CAIRO_RESAMPLE_BEST
>
> defaulting to GOOD, where GOOD then would mean "make it look good".

+1

I don't appreciate the differences between interpolation and sampling,
and I'm certain my (end)users wouldn't.
Whatever Cairo eventually offers, I will likely just wrap+expose with
abstract FAST/GOOD/BEST options (At least, until a knowledgeable user
needs more specific control, if ever ...)

PS: My more interesting downscaling concern/goal would be about
downscaling *huge* source images to a reasonable (ie on-screen) size,
but that's probably a whole different discussion ...

Ian

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: freetype on windows

2009-11-27T08:36:52Z

Hi Shixin,

Looks interesting. Do you use some existing set of libraries that mimic the UNIX enviroment? Or do you implement it all on your own?

Mikhail

27.11.09, 10:25, "Shixin Zeng" <zeng.shixin@...>:

> I have a repository with an ambition to build as many gnome apps on
> windows with MSVC as possible, where includes freetype. It's based on
> scons and still in progress, and I'm just building some gnome related
> libraries.
>
> The repository is located at:http://github.com/zsx/freetype2
> The instructions:http://code.google.com/p/gnome4win/wiki/GetStarted
>
> Best Regards
>
> Shixin Zeng
>
>
>
> On Fri, Nov 27, 2009 at 10:09 AM, Kozhevnikov Mikhail
> wrote:
> > Hi,
> >
> > I've got a bug report for Dingo on Windows having some fonts displayed incorrectly. It appears to be again the same one mentioned here http://lists.cairographics.org/archives/cairo/2009-October/018321.html.
> > I thought of using Freetype font backend to fix this. However, there's a problem as Dingo is built with MSVC, while fontconfig.h requires unistd.h.
> >
> > Has anyone tried using freetype on Windows with MSVC?
> >
> > Cheers,
> > Mikhail.
> >
> > --
> > cairo mailing list
> > cairo@...
> > http://lists.cairographics.org/mailman/listinfo/cairo
> >
>
>

--
Яндекс.Почта. Письма есть. Спама - нет. http://mail.yandex.ru/nospam/sign
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: freetype on windows

2009-11-27T08:25:40Z

I have a repository with an ambition to build as many gnome apps on
windows with MSVC as possible, where includes freetype. It's based on
scons and still in progress, and I'm just building some gnome related
libraries.

The repository is located at:http://github.com/zsx/freetype2
The instructions:http://code.google.com/p/gnome4win/wiki/GetStarted

Best Regards

Shixin Zeng

On Fri, Nov 27, 2009 at 10:09 AM, Kozhevnikov Mikhail
<mikhailkozhevnikov@...> wrote:

> Hi,
>
> I've got a bug report for Dingo on Windows having some fonts displayed incorrectly. It appears to be again the same one mentioned here http://lists.cairographics.org/archives/cairo/2009-October/018321.html.
> I thought of using Freetype font backend to fix this. However, there's a problem as Dingo is built with MSVC, while fontconfig.h requires unistd.h.
>
> Has anyone tried using freetype on Windows with MSVC?
>
> Cheers,
> Mikhail.
>
> --
> cairo mailing list
> cairo@...
> http://lists.cairographics.org/mailman/listinfo/cairo
>

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

freetype on windows

2009-11-27T08:09:47Z

Hi,

I've got a bug report for Dingo on Windows having some fonts displayed incorrectly. It appears to be again the same one mentioned here http://lists.cairographics.org/archives/cairo/2009-October/018321.html.
I thought of using Freetype font backend to fix this. However, there's a problem as Dingo is built with MSVC, while fontconfig.h requires unistd.h.

Has anyone tried using freetype on Windows with MSVC?

Cheers,
Mikhail.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Cairo Drawing Speed

2009-11-27T08:02:09Z

On Tuesday 24 November 2009, Koen Kooi wrote:

> On 24-11-09 14:56, Jonathan Morton wrote:
> > There are a lot of
> >
> > performance enhancements done, especially for ARM processors.
> >
> >
> > I feel obliged to point out that an ARM920T won't be able to take
> > advantage of either the NEON or ARM-SIMD kernels in Pixman - it's a v5
> > chip, so it's like asking a classic Pentium to understand SSE.
>
> Worse, arm920t is armv4t, arm926 is v5.

I still have some armv6 SIMD patches (a few 16bpp fast paths) not yet merged
into pixman. They were used on Nokia N810

As for the older ARM chips, I'm not quite sure if they are going to
be still used in new devices running more or less normal linux software
stack (including pixman). Of course if somebody is up to also optimizing
pixman for armv4 chips, it would be only encouraged I guess.

--
Best regards,
Siarhei Siamashka

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

signature.asc (196 bytes) Download Attachment

Re: Paginating a png image.

2009-11-27T07:54:34Z

> Date: Fri, 27 Nov 2009 09:19:32 +0200
> From: Gerdus van Zyl
> Subject: Re: [cairo] Paginating a png image.
> To: cairo@...
> Message-ID:
> <91882ea90911262319k2a9fb179u1f419cdaa900f5c2@...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> I think you need to keep the rectangle the same:
> cairo_rectangle (cr, 0.0, 0.0, (double)width, (double)page_height);
>
> and move the offset to the source:
> cairo_set_source_surface (cr, the_surface, 0.0,
> (double)page_height*page_nr); //the y could also be negative can't
> remember

Thanks! with a negative offset in there it works.
Richard Shann

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Pixman scaling performance

2009-11-27T07:27:48Z

On Friday 27 November 2009, Soeren Sandmann wrote:

> Siarhei Siamashka <siarhei.siamashka@...> writes:
> > It's mostly a question about the status of
> > http://cgit.freedesktop.org/~sandmann/pixman/log/?h=unroll
> > branch, which should improve performance of nearest scaling.
> >
> > If tested with render_bench program on ARM Cortex-A8, we get the
> > following results (it's mostly showing the performance of OVER
> > compositing operation with nearest or bilinear scaling).
> >
> > As expected, bilinear scaling improved a lot in git (almost reaching
> > imlib2), but nearest scaling is still a bit too slow.
> >
> > Both SRC and OVER operations are quite important for browsers.
>
> I was hoping that someone would take your old scaling fast paths and
>
> - do them with preprocessor macros instead of duplicating them
>
> - go through the fast path system on top of the 'flags' branch
> instead of the additional if statements.
>
> But it may make sese to merge the unroll branch regardless.

Well, looks like we had a little bit of miscommunication then.

Generally I see three layers in pixman:

1. Fully functional simple implementations. Can be used as a reference
implementation and also in the cases which are not supported by fast paths.
2. Some portable fast path C implementations, which implement some subsets of
operations but have lower computational complexity and better performance for
the cases they can handle. Can be used on the platforms which do not have
special hardware-specific optimizations and should preferably provide
sufficient performance not to lose badly to competing libraries :)
Also can be used for benchmarking platform-specific optimizations against
them.
3. Platform-specific optimizations which push performance up to the hardware
limits.

Automated testing can help to compare these alternative implementations to
each other. Tests should be sensitive enough to easily detect problems in
corner cases (like bugs related to '<=' vs. '<' operator usage in 'if'
expression, etc.). Tests themselves can be tested by trying to artificially
introduce bugs into code and checking whether they get caught.

Both your patch from 'unroll' branch and my older nearest neighbor scaling
patch belong to the second layer. They are more or less comparable to each
other. Your patch is more generic and supports more cases of clipping. My
patch was somewhat faster on ARM (with almost no performance difference on
x86).

In any case, I'm most interested in the third layer and ARM specific
optimizations (for scaling too). That's why I would like to see 'unroll'
branch merged so that we can move on. It's nice to see pixman performance
improving steadily.

--
Best regards,
Siarhei Siamashka

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

signature.asc (196 bytes) Download Attachment

Re: [PATCH] pixman: high qualtiy downscaling

2009-11-27T04:18:13Z

Carlos Garcia Campos <carlosgc@...> writes:

> What's the status of this? any chance of getting this fixed in
> pixman soon? Poppler has been affected by this bug[1] for a long
> time, and it's the main reason why we still allow building
> poppler-glib frontend with the splash backend. If there's anything I
> can do to help, please let me know.

My opinion on the subject is basically still here:

http://lists.cairographics.org/archives/cairo/2009-June/017498.html

A quite general solution would be to add the ability to resample at a
user-specified rate with a user-specified filter kernel. A first
implementation of this could offer just a box filter.

In practical terms, this would mean changing the fetching in
pixman-bits-image.c to fetch subpixels and average them together
instead of fetching whole pixels.

A new function

pixman_image_set_resample_rate (image, rate_x, rate_y)

would be added, where rate_x and rate_y both default to 1. If they are
set to something other than 1, then a different fetch function is
installed that fetches rate_x times rate_y subpixels per pixel, then
averages them together. I don't think this would be a huge amount of
work to do.

To get approximately GdkPixbuf level of quality, you could then do:

if downscaling in the X direction, then
rate_x = 1 / scale_ratio_x
else
rate_x = 1;

if downscaling in the Y direction, then
rate_y = 1 / scale_ratio_y
else
rate_x = 1;

if (rate_x == 1 || rate_y == 1)
filter = PIXMAN_FILTER_BILINEAR;
else
filter = PIXMAN_FILTER_NEAREST;

pixman_image_set_filter (image, filter);
pixman_image_set_resample_rate (image, rate_x, rate_y);

Though, there could be aliasing issues resulting from the combination
of nearest interpolation with super sampling where some source pixels
may get disproportionately overrepresented. BILINEAR could be used in
all cases if this is a problem.

- Cairo API -

Corresponding cairo API would have to be added. Below are some
thoughts on that. They should not be taken as fully formed proposal.

The direct translation of the pixman API would be:

cairo_pattern_set_resampling_rate (pattern, rate_x, rate_y)
cairo_pattern_set_resampling_filter (pattern, filter).

and that would enough for a sufficiently motivated developer to get
reasonable rescaling, but you have to write basically the code above,
so there likely should be some simplified API to let users say "please
just make it look reasonable".

Maybe that is CAIRO_FILTER_GOOD, but that would conflate interpolatino
and sampling, which would bug me. Another possibility is that cairo
simply offers

CAIRO_RESAMPLE_FAST
CAIRO_RESAMPLE_GOOD
CAIRO_RESAMPLE_BEST

defaulting to GOOD, where GOOD then would mean "make it look good".

Another issue is how/whether to configure resampling of masks. Having
this ability is interesting because it gives us these features:

- resampling with a gaussian kernel gives us blurring of both
images and geometry

- using a better kernel than the current box filter could
potentially give higher quality antialiasing.

- setting the sampling rate to something other than 17x15 gives a
user-settable tradeoff between speed and quality geometry
rendering.

Thanks,
Soren
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: [PATCH] [pixman-test]: support for testing pixbuf fast path functions in blitters-test

2009-11-27T04:14:20Z

Siarhei Siamashka <siarhei.siamashka@...> writes:

> This is a patch for extending 'blitters-test' to also cover pixbuf related
> fast path functions in pixman.

Looks good to me.

Thanks,
Soren
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Pixman scaling performance

2009-11-27T04:11:41Z

Siarhei Siamashka <siarhei.siamashka@...> writes:

> It's mostly a question about the status of
> http://cgit.freedesktop.org/~sandmann/pixman/log/?h=unroll
> branch, which should improve performance of nearest scaling.
>
> If tested with render_bench program on ARM Cortex-A8, we get the
> following results (it's mostly showing the performance of OVER
> compositing operation with nearest or bilinear scaling).
>
> As expected, bilinear scaling improved a lot in git (almost reaching
> imlib2), but nearest scaling is still a bit too slow.
>
> Both SRC and OVER operations are quite important for browsers.

I was hoping that someone would take your old scaling fast paths and

- do them with preprocessor macros instead of duplicating them

- go through the fast path system on top of the 'flags' branch
instead of the additional if statements.

But it may make sese to merge the unroll branch regardless.

Soren
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: [PATCH, pixman] Eliminate fast path flags

2009-11-27T03:44:44Z

Siarhei Siamashka <siarhei.siamashka@...> writes:

> > Yeah, we should probably at have at least two CRC32 values, one for
> > the 2 million case, and one for a 100 million case that could run
> > overnight.
> >
> > It might also be interesting to have many more than two values, and
> > store them in a table where each row would contain both CRC and seed
> > for 2 million iterations, for 4 million, for 6 million and so on.
> >
> > The test could then pick a range to run at random, which would
> > substantially increase the coverage.
>
> The problem is that performance of different systems may vary a lot, so 100
> millions may be fine for one system, but too much for the other.

I am saying that there would be a table like this:

{ <seed>, <crc value> }, /* after 1000000 iterations */
{ <seed>, <crc value> }, /* after 2000000 iterations */
{ <seed>, <crc value> }, /* after 3000000 iterations */
{ <seed>, <crc value> }, /* after 4000000 iterations */
{ ... },

and so on. The test suite could then do these things:

(1) It could pick a random number k between 0 and 99 (with a seed of
current time), then run that range of tests, using the seed and CRC
from row[k-1] as the starting seeds and CRCs.

After running those 1000000 iterations it would compare the crc value
to the one in in row[k] and fail the test if they didn't match. (It
could also compare the seed values and complain that the test table
itself was broken).

(2) It could repeat (1) until you stopped it

(3) It could run all 100 tests.

I think this would substantially increase the coverage from the
test. Of course, maybe 100 is not the right number.

> For modern systems it probably also makes sense to add multithreading
> support to the test so that it can utilize all the available CPU
> cores.

Agreed.

Soren
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: OpenType fonts in Windows Metafiles

2009-11-27T02:00:05Z

Zoltán Turányi wrote:
> I attached two emf files showing the drawing and the resulting wmf files
> that does/does not have the text in them. (Note that wmf files have a
> thumbnail bitmap stored with them, which shows the text, but if you drop
> the wmf onto a PowerPointslide, it misses the text.)

All your emf/wmf attachments render correctly in Windows Picture Viewer
and EMFexplorer. Maybe it is a bug in the application you are importing
the files into.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Paginating a png image.

2009-11-26T23:19:32Z

I think you need to keep the rectangle the same:
cairo_rectangle (cr, 0.0, 0.0, (double)width, (double)page_height);

and move the offset to the source:
cairo_set_source_surface (cr, the_surface, 0.0,
(double)page_height*page_nr); //the y could also be negative can't
remember

~G

On Thu, Nov 26, 2009 at 8:59 PM, Richard Shann <richard.shann@...> wrote:

> I am trying to print a .png image which is created by an external
> application as several pages abutted vertically. (That is the width is
> the width of A4 paper, the height is number_pages * the height of A4).
>
> I am using the GtkPrintOperation, and can get the first page, but the
> subsequent pages are (largely) blank.
>
> In the callback for the begin-print I set up the cairo surface
> and compute the number of pages from by scaling by 842/595 which is A4
> aspect ratio.
>
> the_surface = cairo_image_surface_create_from_png (image.png);
> int src_width = cairo_image_surface_get_width(the_surface);
> int src_height = cairo_image_surface_get_height(the_surface);
>
> int width = 595;
> int height = 842;
> int page_height = height*((double)src_width)/width;
> int num_pages = src_height/page_height;
> gtk_print_operation_set_n_pages (operation, num_pages);
>
> Then with the draw-page callback I try to take each chunk of the image,
> and this is where I guess I make some mistake:
>
> cairo_t * cr = gtk_print_context_get_cairo_context (context);
> cairo_set_source_surface (cr, the_surface, 0.0, 0.0);
> cairo_rectangle (cr, 0.0, (double)page_height*page_nr,
> (double)width, (double)page_height);
> cairo_fill (cr);
>
> That is, I move the y-coordinate of the cairo_rectangle on by one
> page_height at each call expecting this to take a new page from the
> image surface. However only the value page_nr=0 behaves as expected, the
> second page has just a tiny strip from the bottom of the first page,
> printed at the bottom, and the rest of the pages are blank.
>
> Any help would be appreciated
>
> Richard Shann
>
>
>
>
> --
> cairo mailing list
> cairo@...
> http://lists.cairographics.org/mailman/listinfo/cairo
>

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Building Cairo with only Image and PNG surfaces

2009-11-26T18:41:11Z

Hi Mohit,

I‘ve also encountered the same situation.

In order to avoid it, I tried adding the necessary src files into my CairoBuildProject one by one, meanwhile building the project step by step.

On Thu, Nov 26, 2009 at 7:03 PM, Mohit Sindhwani <ml3p@...> wrote:

Mars Depp wrote:

I don't know if you have turn on the switch of WIN32 backend.
Have a try, add "#define CAIRO_HAS_WIN32_SURFACE 1 " to "cairo-features.h", which included by "cairo.h".
Good luck~

Hi Mars

Thanks for the reply.

I have tried that. I am actually trying to build without the WIN32 surface since that gives numerous problems on Windows CE.

Cheers,
Mohit.
11/26/2009 | 7:03 PM.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Awful PDF output from Evince

2009-11-26T14:32:48Z

Behdad Esfahbod wrote:
> No, on the contrary: it includes thousands of small fallback images,
> typically a few pixels wide and high!

This looks like it is printing each Type 3 glyph as an image. This was a
bug that was fixed in poppler 0.12.0 when I made poppler-cairo use user
fonts for Type 3 fonts. It works for me using poppler master.

--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Awful PDF output from Evince

2009-11-26T14:13:15Z

On 11/26/2009 04:59 PM, Adrian Johnson wrote:

> Behdad Esfahbod wrote:
>> When I try printing this PDF:
>>
>> http://www.toronto.diplo.de/Vertretung/toronto/en/04/VisaRegulations/downloaddatei__visaform__schengen,property=Daten.pdf
>>
>>
>> using evince into a new PDF (I'm trying to shrink it from A4 to
>> Letter), I get a 23MB output. The original is 91K!
>>
>> Printing to PS is slightly better. Comes out at 5MB.
>>
>> Both outputs take a LONG LONG time to render in evince. And the
>> printer didn't like them either.
>>
>> Cheers,
>> behdad
>
>
> I printed your PDF to PDF and PS using code similar to the PS/PDF
> rendering example [1] and get a 215k PDF and 614k PS.
>
> Does the PS file contain one big image? It may be an evince bug.

No, on the contrary: it includes thousands of small fallback images,
typically a few pixels wide and high!

behdad:~ 0$ grep 'Fallback' output.ps | wc -l
8229
behdad:~ 0$ grep 'Fallback' output.ps | tail
% Fallback Image: x=189, y=761, w=7, h=1 res=300dpi size=450
% Fallback Image: x=200, y=761, w=3, h=1 res=300dpi size=195
% Fallback Image: x=206, y=761, w=4, h=1 res=300dpi size=255
% Fallback Image: x=211, y=761, w=5, h=1 res=300dpi size=315
% Fallback Image: x=217, y=761, w=4, h=1 res=300dpi size=255
% Fallback Image: x=224, y=761, w=3, h=1 res=300dpi size=195
% Fallback Image: x=231, y=761, w=4, h=1 res=300dpi size=255
% Fallback Image: x=120, y=762, w=4, h=1 res=300dpi size=255
% Fallback Image: x=177, y=762, w=4, h=1 res=300dpi size=255
% Fallback Image: x=231, y=762, w=4, h=1 res=300dpi size=255

>
> [1] http://www.cairographics.org/renderpdf/
>
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

Re: Awful PDF output from Evince

2009-11-26T13:59:05Z

Behdad Esfahbod wrote:

> When I try printing this PDF:
>
> http://www.toronto.diplo.de/Vertretung/toronto/en/04/VisaRegulations/downloaddatei__visaform__schengen,property=Daten.pdf
>
> using evince into a new PDF (I'm trying to shrink it from A4 to Letter), I get
> a 23MB output. The original is 91K!
>
> Printing to PS is slightly better. Comes out at 5MB.
>
> Both outputs take a LONG LONG time to render in evince. And the printer
> didn't like them either.
>
> Cheers,
> behdad

I printed your PDF to PDF and PS using code similar to the PS/PDF
rendering example [1] and get a 215k PDF and 614k PS.

Does the PS file contain one big image? It may be an evince bug.

[1] http://www.cairographics.org/renderpdf/
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo