Nabble - Free Desktop - Cairo

Re: Video Hackfest conclusions

2009-12-02T15:00:26Z

Siarhei Siamashka wrote:

> 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.

I think he is talking about using bilinear to get the Cb and Cr
intermediate data from 4:2:2 or 4:1:1 YCbCr data. This would be lossless
(other than the rounding and truncation) provided one pixel has the
exact original Cb or Cr value. The pixels between that one and the next
exact pixel would have an interpolated value. Then the encoder and
decoder have to agree to use the same pixels.

It would lose a lot of data however if the image is shifted by 1 pixel
and then converted back. In effect it would blur the Cb and Cr channels
by a 2-pixel box filter. If that is a concern, I do see it working
better to dupliate the Cb and Cr exactly to a block of 2 or 4 pixels
when converting from 4:2:2 or 4:1:1.

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

From forum: Free Desktop - Cairo - General

Re: windows metafile writing bug

2009-12-02T14:10:49Z

Kozhevnikov Mikhail wrote:
> Hi,
>
> I've been refactoring some Cairo-related code in my project and faced again the issue I've already told about ().
>
> If I render some text to a PNG, it works fine, but when using EMF, the text is gone (while graphics are displayed correctly in both cases) - see the code attached for a sample. I'd consider it a bug.
>
> Cheers,
> Mikhail.
>

What cairo version are you using? The 1.9.4 snapshot contains a fix for
missing text in EMF files.

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

From forum: Free Desktop - Cairo - General

Re: how to increase a new operator in cairo

2009-12-02T09:30:24Z

Liang Wang <bluepower1983@...> writes:

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

As far as pixman is concerned, I think support for raster operations
would be a useful addition. The way I would do that is to move the
code for the CopyArea() operation (and possibly the other core
operations) from the X server into pixman.

I'm not sure raster operations make sense as part of the cairo API
(since it is fundamentally dealing with colors and not pixel values).

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

From forum: Free Desktop - Cairo - General

Re: pixman: New ARM NEON optimizations

2009-12-02T07:43:41Z

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

> As you noticed earlier, software RENDER extension implementation in xserver
> suffers from creating and destroying temporary pixman_image_t structures for
> each operation in fbComposite function (PicturePtr and pixman_image_t are
> practically duplicates of each other). But this is not a good excuse to be
> wasteful regarding CPU cycles in pixman too. If anything can be simplified and
> optimized even a bit with relatively little efforts, probably this should be
> done. Or is it better to fix xserver first and then look at pixman performance
> again?

As long as the X server is creating and destroying images all the
time, I don't think it makes a lot of sense to optimize pixman for
tiny images.

When the X server is fixed, it would make a lot of sense to look into
how to get pixman to deal with tiny images, whether they are glyphs or
just small, general images. The flags branch helps a bit with that,
but there is still overhead on some profiles.

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

From forum: Free Desktop - Cairo - General

Re: windows metafile writing bug

2009-12-02T04:58:01Z

Sorry, forgot a link to the old thread: http://lists.freedesktop.org/archives/cairo/2008-November/015861.html

That time Dominic recommended to play around StartPage/EndPage/cairo_surface_show_page but it seems to make no difference in my case.

Cheers,
Mikhail.

02.12.09, 15:51, "Kozhevnikov Mikhail" :

> Hi,
>
> I've been refactoring some Cairo-related code in my project and faced again the issue I've already told about ().
>
> If I render some text to a PNG, it works fine, but when using EMF, the text is gone (while graphics are displayed correctly in both cases) - see the code attached for a sample. I'd consider it a bug.
>
> Cheers,
> Mikhail.
>

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

From forum: Free Desktop - Cairo - General

windows metafile writing bug

2009-12-02T04:51:41Z

Hi,

I've been refactoring some Cairo-related code in my project and faced again the issue I've already told about ().

If I render some text to a PNG, it works fine, but when using EMF, the text is gone (while graphics are displayed correctly in both cases) - see the code attached for a sample. I'd consider it a bug.

Cheers,
Mikhail.
#include <windows.h>
#include <cairo.h>
#include <cairo-win32.h>

void TestWin32Emf (bool metafile)
{
cairo_surface_t *surface;
cairo_t *cr;
HDC hdc;
if (metafile)
{
hdc = CreateEnhMetaFile(NULL, "test.emf", NULL, "Test\0\0");
surface = cairo_win32_printing_surface_create (hdc);
}
else
surface = cairo_image_surface_create (CAIRO_FORMAT_ARGB32, 600, 600);
cr = cairo_create(surface);

LOGFONTW lf;
lf.lfHeight = lf.lfWidth = 1;
lf.lfEscapement = lf.lfOrientation = 0;
lf.lfWeight = FW_NORMAL;
lf.lfItalic = lf.lfUnderline = lf.lfStrikeOut = false;
lf.lfCharSet = DEFAULT_CHARSET;
lf.lfOutPrecision = OUT_DEFAULT_PRECIS;
lf.lfClipPrecision = CLIP_DEFAULT_PRECIS;
lf.lfQuality = CLEARTYPE_QUALITY;
memcpy(lf.lfFaceName, L"Arial", sizeof(L"Arial"));

cairo_font_face_t *ff = cairo_win32_font_face_create_for_logfontw(&lf);
cairo_matrix_t font_scale, ctm;
cairo_matrix_init_identity(&ctm);
cairo_matrix_init_identity(&font_scale);
cairo_matrix_scale(&font_scale, 14, 14);
cairo_font_options_t *fopt = cairo_font_options_create();
cairo_scaled_font_t*sf = cairo_scaled_font_create(ff, &font_scale, &ctm, fopt);
cairo_set_source_rgb(cr, 0, 0, 0);

const char* txt = "0";
cairo_set_scaled_font(cr, sf);
cairo_text_extents_t ext;
cairo_text_extents(cr, txt, &ext);
for (int j = 0; j < 50; ++j)
for (int i = 0; i < 50; ++i)
{
cairo_move_to(cr, (ext.width * (1.999 + j * 0.0005)) * i + 20, j * (1.5f * ext.height) + 11);
cairo_show_text(cr, txt);
}

cairo_destroy(cr);
if (!metafile)
cairo_surface_write_to_png(surface, "test.png");
cairo_surface_destroy(surface);
if (metafile)
CloseEnhMetaFile(hdc);
}

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

From forum: Free Desktop - Cairo - General

Re: Awful PDF output from Evince

2009-12-02T01:08:16Z

Excerpts from Behdad Esfahbod's message of mar dic 01 22:51:14 +0100 2009:

> On 11/26/2009 05:32 PM, Adrian Johnson wrote:
> > 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.
>
> I updated to poppler master. That fixed the print issue, but then evince
> renders those Type3 fonts unreadably distorted and pixelated. Have not
> debugged it yet.

This is another cairo bug introduced by this commit:

http://cgit.freedesktop.org/cairo/commit/?id=a2254e56474fcdf5f25232812cdbef30a2b5ea60

> Independently, it probably makes sense to merge nearby fallback areas...
>
> behdad
--
Carlos Garcia Campos
PGP key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x523E6462

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

signature.asc (204 bytes) Download Attachment

From forum: Free Desktop - Cairo - General

Re: RenderBadGlyphSet (invalid GlyphSet parameter)

2009-12-02T00:57:15Z

On Wed, 2 Dec 2009 14:41:08 +1100, Simon Burton <simon@...> wrote:
> I am using the cairo xlib surface, and I got this error on
> one of the X servers we run:
>
> 'RenderBadGlyphSet (invalid GlyphSet parameter)'.
> (Details: serial 339 error_code 171 request_code 151 minor_code 20)
>
> Has anyone seen this error before ? I also use gtk so I suppose it could
> be a gtk problem. Or maybe I am confusing my cairo contexts.

No, the only time I've see that type of error is when developing the code.
Let me make a guess about your code: multi-threaded, long-lived contexts,
contexts moving between threads?

Glyphs and glyphsets are meant to be only manipulated whilst holding the
font mutex, but we have the extra twist of trying to ensure serialised
access to the Display. In 1.8, this is done by queueing work and running all
pending tasks for a Display at the start of the function (when we know we
have a valid thread context for the Display - multithreading in xlib is not
fun). This is the most probable window for a race between multiple
rendering threads.

Of course this whole supposition is moot if you are not writing a
multithreaded application... If you are, then you will be looking forward to
1.10 where we are aiming to fix a few of the remaining tiny race windows for
multiple rendering threads and xlib.
-ickle

--
Chris Wilson, Intel Open Source Technology Centre
--
cairo mailing list
cairo@...
http://lists.cairographics.org/mailman/listinfo/cairo

From forum: Free Desktop - Cairo - General

RenderBadGlyphSet (invalid GlyphSet parameter)

2009-12-01T19:41:08Z

I am using the cairo xlib surface, and I got this error on
one of the X servers we run:

'RenderBadGlyphSet (invalid GlyphSet parameter)'.
(Details: serial 339 error_code 171 request_code 151 minor_code 20)

Has anyone seen this error before ? I also use gtk so I suppose it could
be a gtk problem. Or maybe I am confusing my cairo contexts.

thanks,

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

From forum: Free Desktop - Cairo - General

Re: Awful PDF output from Evince

2009-12-01T14:14:51Z

Behdad Esfahbod wrote:

> On 11/26/2009 05:32 PM, Adrian Johnson wrote:
>> 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.
>
> I updated to poppler master. That fixed the print issue, but then evince
> renders those Type3 fonts unreadably distorted and pixelated. Have not
> debugged it yet.

Works fine for me using either the versions in Ubuntu 9.10 or with
evince/poppler/cairo master.

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

From forum: Free Desktop - Cairo - General

Re: Awful PDF output from Evince

2009-12-01T13:51:14Z

On 11/26/2009 05:32 PM, Adrian Johnson wrote:
> 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.

I updated to poppler master. That fixed the print issue, but then evince
renders those Type3 fonts unreadably distorted and pixelated. Have not
debugged it yet.

Independently, it probably makes sense to merge nearby fallback areas...

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

From forum: 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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General

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

From forum: Free Desktop - Cairo - General