702158 - [Skia] Get Skia backend working on Linux

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Matt Woodrow (:mattwoodrow)]

It would be nice to have skia building and running on linux, similar to bug 699258 for windows.

If anyone wants to give this a go, I'd be happy to provide support.

Comment 1

[Marco Castelluccio [:marco]]

I think I can do this, as I've experience in this field :D

Comment 2

[Marco Castelluccio [:marco]]

The patch is almost ready, but I've a problem in linking because of missing freetype FT_* functions (also with OS_CXXFLAGS += $(CAIRO_FT_CFLAGS)).
We use freetype in Linux, don't we?

Comment 3

[Matt Woodrow (:mattwoodrow)]

We do, yes.

Can you post your patches, and I'll have a look

Comment 4

[Benoit Jacob [:bjacob] (mostly away)]

Just noting that this could also very well be the savior of OpenGL layers acceleration on Linux (bug 594876). It's proven very hard to turn on OpenGL layers acceleration on linux (layers.acceleration.force-enabled=true) due to interoperability problems with XRender and driver bugs around the texture_from_pixmap extension. If Skia doesn't touch XRender at all, contrary to Cairo, then switching to it should solve problems here.

Comment 5

[Marco Castelluccio [:marco]]

Attachment: Skia Linux

Comment 6

[Matt Woodrow (:mattwoodrow)]

I'm a bit stuck here trying to this to link.

When linking with gold we get:

/usr/bin/ld.gold.real: error: hidden symbol 'FT_Done_Size' is not defined locally

And many more.

Looking at a working build of libxul (from trunk) : http://pastebin.mozilla.org/1405738

We can see that linking to freetype was successful, and that the symbols we need are there and not marked as hidden. I really have no idea why FT_Done_Face (used in existing areas of our code) links fine, and FT_Done_Size (only used in Skia) does not.

For reference, this patch (http://sourceware.org/ml/binutils/2010-01/msg00278.html) added the error we are getting which means that gold is seeing the symbol as HIDDEN, even though readelf shows it as DEFAULT.

Comment 7

[Matt Woodrow (:mattwoodrow)]

Cc'ing glandium as someone who might have some insight into these errors.

Note that this also fails to link with ld, the gold errors just appeared to be more meaningful.

Comment 8

[Nathan Froyd [:froydnj]]

Are you sure that the libfreetype.so you're linking against is the same libfreetype.so.6 that ldd is finding?  You didn't indicate whether that was the case in your debugging output.

Comment 9

[Matt Woodrow (:mattwoodrow)]

I'm not sure, how can I get the linker to tell me which binary it found when looking for -lfreetype?

Comment 10

[Nathan Froyd [:froydnj]]

With GNU ld, something like -Wl,-Map -Wl,mapfile.txt will dump a bunch of information to mapfile.txt; I think information about the exact shared libraries should be in there.  I don't know if gold supports the same option or not.

Comment 11

[Mike Hommey [:glandium]]

Some freetype headers are missing in config/system-headers.

Comment 12

[Matt Woodrow (:mattwoodrow)]

Attachment: Skia Linux v2

Thanks glandium, that was indeed the problem.

Updated patch that builds and links correctly.

Comment 13

[Benoit Jacob [:bjacob] (mostly away)]

\o/ \o/ \o/

Let beer flow for Marco, Matt and Glandium.

    .o.  o.  .
 oO8oo8O8OooOOO
O8oo8O88ooo88o8o.
o|oO.O8.ooO8o.o|
 | o  .    o   |/=\
 | .       .   |  |
 | .       .   |  |
 |             |  |
 |             |  /
 |             |/
 |             |
 \=============/

Comment 14

[Marco Castelluccio [:marco]]

Attachment: Skia Linux v3

I've rebased the patch and sent to try: https://tbpl.mozilla.org/?tree=Try&rev=d834a6e15ca0.

Thanks Benoit :D

Comment 15

[Marco Castelluccio [:marco]]

/usr/bin/ld: libxul.so: hidden symbol `FT_Get_X11_Font_Format' isn't defined

Probably it's another missing header file, but on my desktop machine it builds.

Comment 16

[Marco Castelluccio [:marco]]

That function is in the header file ftxf86.h, I'll do another try build asap.

Comment 17

[Marco Castelluccio [:marco]]

I've checked better and the file is actually included (it's included by SkFontHost_FreeType.cpp).

However there are two different build errors.
In Linux:
> /usr/bin/ld: libxul.so: hidden symbol `FT_Get_X11_Font_Format' isn't defined
> /usr/bin/ld: final link failed: Nonrepresentable section on output"

In Linux64:
> ../../gfx/skia/SkFontHost_FreeType.o: In function `SkFontHost::GetAdvancedTypefaceMetrics(unsigned int, SkAdvancedTypefaceMetrics::PerGlyphInfo, unsigned int const*, unsigned int)':
> /builds/slave/try-lnx64-dbg/build/gfx/skia/src/ports/SkFontHost_FreeType.cpp:437: undefined reference to `FT_Get_X11_Font_Format'
> /usr/bin/ld: ../../gfx/skia/SkFontHost_FreeType.o: relocation R_X86_64_PC32 against `FT_Get_X11_Font_Format' can not be used when making a shared object; recompile with -fPIC
> /usr/bin/ld: final link failed: Bad value

Comment 18

[Mike Hommey [:glandium]]

Visibility issues don't lead to the same linking errors on x86 and x86-64, that's "expected". Both involve the same symbol.

Comment 19

[Benoit Jacob [:bjacob] (mostly away)]

Marking this as blocking bug 594876 (enable GL layers on linux) because it's getting clear that there are too many XRender-related bugs for it to be possible to enable GL layers as long as we also use XRender; and currently the only concrete avenue we have to stop using XRender is to use Skia (theoretically we could also use a different Cairo backend, but i'm not aware of work in this direction).

Comment 20

[Matt Woodrow (:mattwoodrow)]

Looks like your pushed missed include 'ftxf86.h' into the system headers file.

With that added:

Linux opt: Passes

Linux debug & Linux64 debug:

TEST-UNEXPECTED-FAIL | | We don't want these libstdc++ symbols to be used:
00000000      DF *UND*	000001c3  GLIBCXX_3.4.9 _ZNSo9_M_insertIPKvEERSoT_

Linux64 opt:

../../gfx/skia/SkFontHost_FreeType.o: In function `~SkScalerContext_FreeType':
/builds/slave/try-lnx64/build/obj-firefox/gfx/skia/../../../gfx/skia/src/ports/SkFontHost_FreeType.cpp:809: undefined reference to `FT_Done_Size'
/usr/bin/ld: ../../gfx/skia/SkFontHost_FreeType.o: relocation R_X86_64_PC32 against `FT_Done_Size' can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: final link failed: Bad value

FT_Done_Size is from ftsizes.h, which is included in system-headers. It also managed to compile in debug, and on 32bit.

The lidstdc++ symbols problems looks to be more complicated as I assume this symbol is being brought in from libfreetype.

Comment 21

[Marco Castelluccio [:marco]]

Android is building with MOZ_TREE_FREETYPE=1.

However I've made a small (probably useless) change to the patch (MOZ_PANGO_CFLAGS in place of CAIRO_FT_CFLAGS), here is the try push: https://tbpl.mozilla.org/?tree=Try&rev=88bc97b07685

Comment 22

[Marco Castelluccio [:marco]]

Ok, now the problem is only the libstdc++ symbol!

Comment 23

[Marco Castelluccio [:marco]]

Glandium, should I add CPPSRCS += $(STDCXX_COMPAT) to the Skia makefile to get rid of the problem?
Sent to try to see what happens with that added: https://tbpl.mozilla.org/?tree=Try&rev=4c7077cb6874

Comment 24

[Marco Castelluccio [:marco]]

No. But stdc++compat.cpp should avoid GLIBCXX_3.4.9 symbols (as the version of the libstc++ is > than 3.4.9 and that file is compiled and linked to libxul.so).
I can't get why it avoids the symbol on opt builds and not on debug builds.
I'll wait for the opinion of Glandium.

Comment 25

[Mike Hommey [:glandium]]

stdc++compat.cpp voids the symbols that were known to be used at the time it was written. It doesn't try to be exhaustive because there are so many symbols involved, some of which a hack may not even be possible for, and we don't need to be exhaustive. Now, fortunately, you're hitting an easy case, so we can add it.

Comment 26

[Mike Hommey [:glandium]]

Attachment: stdc++compat part

This should work for you.

Comment 27

[Marco Castelluccio [:marco]]

Attachment: Skia Linux v4

Thank you, Glandium. I thought that symbol was yet listed in stdc++compat.cpp, I didn't see the argument was different.

I've attached the latest patch and sent to try: https://tbpl.mozilla.org/?tree=Try&rev=2456d53e8d06

The patches can be checked-in if the build succeeds.

Comment 28

[Matt Woodrow (:mattwoodrow)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/b9e154713763

Comment 29

[Ed Morley [:emorley]]

Backed out of inbound since it is believed to be the cause of pgo linux failures:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound&rev=0af33fc7dbeb

https://tbpl.mozilla.org/php/getParsedLog.php?id=8461377&tree=Mozilla-Inbound
{
rm -f libxul.so
/tools/python/bin/python2.5 /builds/slave/m-in-lnx-pgo/build/config/pythonpath.py -I../../config /builds/slave/m-in-lnx-pgo/build/config/expandlibs_exec.py --uselist --  /usr/bin/ccache /tools/gcc-4.5-0moz3/bin/g++  -fno-rtti -pedantic -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -Wno-long-long -fno-exceptions -fno-strict-aliasing -std=gnu++0x -pthread -ffunction-sections -fdata-sections -pipe  -DNDEBUG -DTRIMMED -g -fprofile-generate -O3 -fomit-frame-pointer -fPIC -shared -Wl,-z,defs -Wl,--gc-sections -Wl,-h,libxul.so -o libxul.so  stdc++compat.i_o nsStaticXULComponents.i_o nsUnicharUtils.i_o nsBidiUtils.i_o nsRDFResource.i_o    -lpthread    -fprofile-generate -Wl,-rpath-link,/builds/slave/m-in-lnx-pgo/build/obj-firefox/dist/bin -Wl,-rpath-link,/usr/local/lib    ../../toolkit/xre/libxulapp_s.a  ../../staticlib/components/libnecko.a ../../staticlib/components/libuconv.a ../../staticlib/components/libi18n.a ../../staticlib/components/libchardet.a ../../staticlib/components/libjar50.a ../../staticlib/components/libstartupcache.a ../../staticlib/components/libpref.a ../../staticlib/components/libhtmlpars.a ../../staticlib/components/libimglib2.a ../../staticlib/components/libgkgfx.a ../../staticlib/components/libgklayout.a ../../staticlib/components/libdocshell.a ../../staticlib/components/libembedcomponents.a ../../staticlib/components/libwebbrwsr.a ../../staticlib/components/libnsappshell.a ../../staticlib/components/libtxmgr.a ../../staticlib/components/libcommandlines.a ../../staticlib/components/libtoolkitcomps.a ../../staticlib/components/libpipboot.a ../../staticlib/components/libpipnss.a ../../staticlib/components/libappcomps.a ../../staticlib/components/libjsreflect.a ../../staticlib/components/libcomposer.a ../../staticlib/components/libtelemetry.a ../../staticlib/components/libjsdebugger.a ../../staticlib/components/libstoragecomps.a ../../staticlib/components/librdf.a ../../staticlib/components/libwindowds.a ../../staticlib/components/libjsctypes.a ../../staticlib/components/libjsperf.a ../../staticlib/components/libgkplugin.a ../../staticlib/components/libunixproxy.a ../../staticlib/components/libjsd.a ../../staticlib/components/libautoconfig.a ../../staticlib/components/libauth.a ../../staticlib/components/libcookie.a ../../staticlib/components/libpermissions.a ../../staticlib/components/libuniversalchardet.a ../../staticlib/components/libfileview.a ../../staticlib/components/libplaces.a ../../staticlib/components/libtkautocomplete.a ../../staticlib/components/libsatchel.a ../../staticlib/components/libpippki.a ../../staticlib/components/libwidget_gtk2.a ../../staticlib/components/libimgicon.a ../../staticlib/components/libprofiler.a ../../staticlib/components/libaccessibility.a ../../staticlib/components/libremoteservice.a ../../staticlib/components/libspellchecker.a ../../staticlib/components/libzipwriter.a ../../staticlib/components/libservices-crypto.a ../../staticlib/libjsipc_s.a ../../staticlib/libdomipc_s.a ../../staticlib/libdomplugins_s.a ../../staticlib/libmozipc_s.a ../../staticlib/libmozipdlgen_s.a ../../staticlib/libipcshell_s.a ../../staticlib/libgfx2d.a ../../staticlib/libgfxipc_s.a ../../staticlib/libhal_s.a ../../staticlib/libxpcom_core.a ../../staticlib/libucvutil_s.a ../../staticlib/libchromium_s.a ../../staticlib/libsnappy_s.a ../../staticlib/libgtkxtbin.a ../../staticlib/libthebes.a ../../staticlib/libgl.a ../../staticlib/libycbcr.a  -L../../dist/bin -L../../dist/lib ../../media/libjpeg/libmozjpeg.a ../../media/libpng/libmozpng.a ../../gfx/qcms/libmozqcms.a /builds/slave/m-in-lnx-pgo/build/obj-firefox/dist/lib/libjs_static.a -L../../dist/bin -L../../dist/lib -lcrmf -lsmime3 -lssl3 -lnss3 -lnssutil3 ../../gfx/cairo/cairo/src/libmozcairo.a  ../../gfx/cairo/libpixman/src/libmozlibpixman.a  -lXrender -lfreetype -lfontconfig ../../gfx/harfbuzz/src/libmozharfbuzz.a  ../../dist/lib/libmozsqlite3.a  ../../gfx/graphite2/src/libmozgraphite2.a ../../modules/zlib/src/libmozz.a ../../dist/lib/libgkmedias.a  -lasound -lm -ldl -lpthread   -lrt ../../gfx/skia/libskia.a -L../../dist/bin -L../../dist/lib  -L/builds/slave/m-in-lnx-pgo/build/obj-firefox/dist/lib -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../../dist/lib/libmozalloc.a -L/lib -ldbus-glib-1 -ldbus-1 -lglib-2.0    -lX11  -lXext  -L/lib -lpangoft2-1.0 -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -L/lib -lgtk-x11-2.0 -latk-1.0 -lgdk-x11-2.0 -lgdk_pixbuf-2.0 -lm -lpangocairo-1.0 -lpango-1.0 -lcairo -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0   -lXt -lgthread-2.0 -lfreetype -ldl  -lrt    
g++: error trying to exec '/tools/gcc-4.5-0moz3/libexec/gcc/i686-pc-linux-gnu/4.5.2/collect2': execv: Argument list too long
}

https://hg.mozilla.org/integration/mozilla-inbound/rev/b6a501cb1a64

Comment 30

[Mike Hommey [:glandium]]

From the same log:
> checking what kind of list files are supported by the linker... linkerscript

I don't understand how we can end up with the Argument list too long error when using a linkerscript :(

Comment 31

[Marco Castelluccio [:marco]]

Glandium, could this be something like bug 644081?
If it's not the case, what if we unset some useless environment variables or increase ARG_MAX? (also if it seems useless if we're using a linker script...)

Comment 32

[Mike Hommey [:glandium]]

bug 644081. mac and linux fail for different reasons. What you want to do is do a try build with pgo enabled, and add verbosity to the build.
pgo can be enabled by putting mk_add_options MOZ_PGO=1 in a mozconfig-extra file at the top-level source directory in what you push to try.
I'd suggest adding --verbose to EXPAND_LIBS_EXEC and --verbose -Wl,--verbose to LDFLAGS.

Comment 33

[Mike Hommey [:glandium]]

(In reply to Mike Hommey [:glandium] from comment #32)
> bug 644081. mac and linux fail for different reasons.

I meant to write that bug 644081 was about mac, not linux.

Comment 34

[Marco Castelluccio [:marco]]

(In reply to Mike Hommey [:glandium] from comment #32)
> bug 644081. mac and linux fail for different reasons. What you want to do is
> do a try build with pgo enabled, and add verbosity to the build.

Yes, I know, but maybe, as we use a linker script, the problem is actually a too long command line as in that bug.

> pgo can be enabled by putting mk_add_options MOZ_PGO=1 in a mozconfig-extra
> file at the top-level source directory in what you push to try.
> I'd suggest adding --verbose to EXPAND_LIBS_EXEC and --verbose -Wl,--verbose
> to LDFLAGS.

Ok, I'll try :)

Comment 35

[Mike Hommey [:glandium]]

(In reply to Marco Castelluccio from comment #34)
> (In reply to Mike Hommey [:glandium] from comment #32)
> > bug 644081. mac and linux fail for different reasons. What you want to do is
> > do a try build with pgo enabled, and add verbosity to the build.
> 
> Yes, I know, but maybe, as we use a linker script, the problem is actually a
> too long command line as in that bug.

The point of using a linker script is that the command line is not used to pass the file list.

Comment 36

[Marco Castelluccio [:marco]]

Attachment: Build log

Sorry, I confused the linker script with something else :D

However I've built Firefox with PGO on my computer, and it isn't failing. I'm using gold as a linker but the log should be the same (i think).

Could you check the build log? If it's useless, I'll push to try.

Comment 37

[Mike Hommey [:glandium]]

The failure happens on the builbots because they are using an old linux kernel. Which is why you don't see it on your machine. So you need to push to try. (and to add --verbose to EXPAND_LIBS_EXEC in config/config.mk)

Comment 38

[Marco Castelluccio [:marco]]

https://tbpl.mozilla.org/?tree=Try&rev=f9f492d2f3dc

Comment 39

[Marco Castelluccio [:marco]]

https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-f9f492d2f3dc/try-linux-debug/try-linux-debug-build5403.txt.gz

Comment 40

[Marco Castelluccio [:marco]]

Added --verbose also to js/src/config/config.mk: https://tbpl.mozilla.org/?tree=Try&rev=c2a1c0f37a1a

Comment 41

[Marco Castelluccio [:marco]]

The builds were successful. Glandium could you check if I did something wrong?

Comment 42

[Mike Hommey [:glandium]]

You did debug builds. debug builds don't do PGO.

Comment 43

[Marco Castelluccio [:marco]]

Here it is, finally: https://tbpl.mozilla.org/?tree=Try&rev=b0bd144a221d

Comment 44

[Marco Castelluccio [:marco]]

Also opt builds were successful. Glandium could you check if I did something wrong?

P.S.: debug builds don't do PGO also if I set MOZ_PGO=1?

Comment 45

[Mike Hommey [:glandium]]

(In reply to Marco Castelluccio from comment #44)
> Also opt builds were successful. Glandium could you check if I did something
> wrong?

It looks like mozconfig-extra isn't read or something, because it's not a PGO build either. You should ask someone from RelEng.

Comment 46

[Ed Morley [:emorley]]

mozconfig-extra no longer works, you need to add the MOZ_PGO=1 line to browser/config/mozconfigs/win32/nightly instead :-)

Comment 47

[Makoto Kato [:m_kato]]

with MOZ_PGO=1

https://tbpl.mozilla.org/php/getParsedLog.php?id=8628790&tree=Try&full=1

g++: error trying to exec '/tools/gcc-4.5-0moz3/libexec/gcc/x86_64-unknown-linux-gnu/4.5.2/collect2': execv: Argument list too long
make[6]: make[6]: Leaving directory `/builds/slave/try-lnx64/build/obj-firefox/toolkit/library'
*** [libxul.so] Error 1

Comment 48

[Makoto Kato [:m_kato]]

Attachment: error log

Comment 49

[Makoto Kato [:m_kato]]

Attachment: workaround for Linux PGO

Comment 50

[Makoto Kato [:m_kato]]

Comment on attachment 590154 [details] [diff] [review]
workaround for Linux PGO

- Use NO_EXPAND_LIBS for too long arguments
- EXPORT_LIBRARY isn't needed for skia

Comment 51

[Mike Hommey [:glandium]]

So, there are actually two build config bugs to file here:
- OBJ_SUFFIX being .o in xpcom/reflect/xptcall/src/md/unix on the first PGO pass.
- expand-libs not handling OBJ_SUFFIX not being .o on the first PGO pass.

The first one is not a big problem, but the second one is definitely why this fails here.

Comment 52

[Mike Hommey [:glandium]]

Comment on attachment 590154 [details] [diff] [review]
workaround for Linux PGO

Let's fix expand-libs instead.

Comment 53

[Makoto Kato [:m_kato]]

reland since try server with PGO is successful.
https://hg.mozilla.org/integration/mozilla-inbound/rev/d49eb8c7238f

Comment 54

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/d49eb8c7238f

Comment 55

[Benoit Jacob [:bjacob] (mostly away)]

So, how do I enable this? Is there a pref?

Comment 56

[Marco Castelluccio [:marco]]

gfx.canvas.azure.enabled

Comment 57

[Benoit Jacob [:bjacob] (mostly away)]

oh ok so this affects only canvas at this point? I need to check the status of the project to use azure for all drawing. What I have in mind is how to stop using pixmaps and xrender, which is holding us back in terms of enabling GL layers on linux. It could be that bug 720523 is needed after all, even with this, if this is only affecting canvas.

Comment 58

[Marco Castelluccio [:marco]]

(In reply to Benoit Jacob [:bjacob] from comment #57)
> oh ok so this affects only canvas at this point? I need to check the status
> of the project to use azure for all drawing. What I have in mind is how to
> stop using pixmaps and xrender, which is holding us back in terms of
> enabling GL layers on linux. It could be that bug 720523 is needed after
> all, even with this, if this is only affecting canvas.

There's gfx.content.azure.enabled to draw also content with Azure (and so Skia), but I don't know if it's used at all on Linux.

Comment 59

[Matt Brubeck (:mbrubeck)]

This patch apparently caused a 5% increase in the "Number of Constructors" measurement on Linux:
https://groups.google.com/d/msg/mozilla.dev.tree-management/AHCC1QDHcMk/y9Ltwknnkp0J

Comment 60

[Makoto Kato [:m_kato]]

(In reply to Matt Brubeck (:mbrubeck) from comment #59)
> This patch apparently caused a 5% increase in the "Number of Constructors"
> measurement on Linux:
> https://groups.google.com/d/msg/mozilla.dev.tree-management/AHCC1QDHcMk/
> y9Ltwknnkp0J

default is off, so I don't think this causes regression.

Comment 61

[Mike Hommey [:glandium]]

(In reply to Makoto Kato from comment #60)
> (In reply to Matt Brubeck (:mbrubeck) from comment #59)
> > This patch apparently caused a 5% increase in the "Number of Constructors"
> > measurement on Linux:
> > https://groups.google.com/d/msg/mozilla.dev.tree-management/AHCC1QDHcMk/
> > y9Ltwknnkp0J
> 
> default is off, so I don't think this causes regression.

Static initializers are always there, skia being on or off.

Comment 62

[Constantine]

Currently azure doesn't work with layers.offmainthreadcomposition.enabled=true. Steps to reproduce:
1. Set up gfx.canvas.azure.enabled=true, gfx.content.azure.enabled=true, layers.acceleration.force-enabled=true, layers.offmainthreadcomposition.enabled=true.
2. Restart FF.
Result: firefox hangs Xorg or crashes with:
   firefox: ../../src/xcb_io.c:140: dequeue_pending_request: Проверочное утверждение «req == dpy->xcb->pending_requests» не выполнено.
   Аварийный останов
My system: Linux x86_64, NVIDIA driver 290.10. Should I file a new bug against it or this may be fixed here?

Comment 63

[Makoto Kato [:m_kato]]

(In reply to konstartyom from comment #62)
> Currently azure doesn't work with
> layers.offmainthreadcomposition.enabled=true. Steps to reproduce:
> 1. Set up gfx.canvas.azure.enabled=true, gfx.content.azure.enabled=true,
> layers.acceleration.force-enabled=true,
> layers.offmainthreadcomposition.enabled=true.
> 2. Restart FF.
> Result: firefox hangs Xorg or crashes with:
>    firefox: ../../src/xcb_io.c:140: dequeue_pending_request: Проверочное
> утверждение «req == dpy->xcb->pending_requests» не выполнено.
>    Аварийный останов
> My system: Linux x86_64, NVIDIA driver 290.10. Should I file a new bug
> against it or this may be fixed here?

It seems to be your driver's bug.  also, you can file a new bug for it.

Comment 64

[Constantine]

Sorry, I figured out this isn't related to Skia but something else.

Comment 65

[Marco Castelluccio [:marco]]

Attachment: Really enable Skia

Sadly there was a problem in enabling the skia backend. Skia wasn't really enabled (because of XP_LINUX, that should be LINUX).

However now Firefox crashes when using Skia:
> Program ./firefox (pid = 9401) received signal 11.
> Stack:
> UNKNOWN [/lib/x86_64-linux-gnu/libpthread.so.0 +0x00010060]
> UNKNOWN [.../libxul.so +0x0140B45A]
> UNKNOWN [.../libxul.so +0x012D1F68]
> UNKNOWN [.../libxul.so +0x012D1F82]
> UNKNOWN [.../libxul.so +0x00A3B69D]
> UNKNOWN [.../libxul.so +0x007C1147]
> UNKNOWN [.../libxul.so +0x00A3E0FA]
> UNKNOWN [.../libxul.so +0x00EFFC15]
> UNKNOWN [.../libxul.so +0x01680F43]
> UNKNOWN [.../libxul.so +0x01679EE1]
> UNKNOWN [.../libxul.so +0x01667AE4]
> UNKNOWN [.../libxul.so +0x0167A0C4]
> UNKNOWN [.../libxul.so +0x0167A922]
> JS_CallFunctionValue+0x0000011E [.../libxul.so +0x015783FE]
> UNKNOWN [.../libxul.so +0x00BB3579]
> UNKNOWN [.../libxul.so +0x00BD43F3]
> UNKNOWN [.../libxul.so +0x00BD47B8]
> UNKNOWN [.../libxul.so +0x01323EEE]
> UNKNOWN [.../libxul.so +0x013240B2]
> UNKNOWN [.../libxul.so +0x0131F95C]
> UNKNOWN [.../libxul.so +0x012DE5F0]
> UNKNOWN [.../libxul.so +0x0122B89C]
> UNKNOWN [.../libxul.so +0x0134A582]
> UNKNOWN [.../libxul.so +0x0134A5AA]
> UNKNOWN [.../libxul.so +0x011AD84F]
> UNKNOWN [.../libxul.so +0x00FFE326]
> XRE_main+0x0000408E [.../libxul.so +0x005A021C]
> UNKNOWN [./firefox +0x00002219]
> __libc_start_main+0x000000ED [/lib/x86_64-linux-gnu/libc.so.6 +0x0002130D]
> UNKNOWN [./firefox +0x00001AE9]

The problem should be related to pthread. But also if I use SkThread_pthread.cpp instead of SkThread_none.cpp, the issue is still there.

Comment 66

[Marco Castelluccio [:marco]]

(Note that the crash doesn't occur on every page with canvas, a crashing example is the testcase in bug 716121, a not crashing example is in bug 722186).

Comment 67

[Marco Castelluccio [:marco]]

I've found another page where Firefox crashes: http://www.kevs3d.co.uk/dev/asteroids/
This is simpler to study, as the code isn't minified.

Comment 68

[Makoto Kato [:m_kato]]

land part2
https://hg.mozilla.org/integration/mozilla-inbound/rev/9eafdaeae378

Comment 69

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/9eafdaeae378

Comment 70

[Daniel C]

Eager to test bug 561361 comment 7, I repeatedly crashed so I filed bug 723168. Let me know if I can help test anything.

Also, drive-by mini-bug 1: can gfx.azure.enabled be a non-hidden pref so that it can just be toggled rather than added? It would make testing easier.

Drive-by mini-bug 2: Reflect the status of gfx.azure.enabled in the Graphics section of about:support.

Thanks.

Comment 71

[Marco Castelluccio [:marco]]

(In reply to Daniel Cater from comment #70)
> Eager to test bug 561361 comment 7, I repeatedly crashed so I filed bug
> 723168. Let me know if I can help test anything.

There's a known problem with font handling.

> Also, drive-by mini-bug 1: can gfx.azure.enabled be a non-hidden pref so
> that it can just be toggled rather than added? It would make testing easier.

This is a highly experimental feature, a hidden pref is better for now.

> Drive-by mini-bug 2: Reflect the status of gfx.azure.enabled in the Graphics
> section of about:support.

When you're using Skia, in about:support there's Skia as AzureBackend. If Azure isn't enabled, AzureBackend isn't present.

Comment 72

[Daniel C]

(In reply to Marco Castelluccio from comment #71)
> When you're using Skia, in about:support there's Skia as AzureBackend. If
> Azure isn't enabled, AzureBackend isn't present.

That doesn't appear to be the case. I see:

AzureBackend: skia

in a clean profile and in a profile with gfx.azure.enabled explicitly set to false.

Comment 73

[Marco Castelluccio [:marco]]

Sorry, you were right :)
Could you file a new bug about this issue?

Comment 74

[Daniel C]

(In reply to Marco Castelluccio from comment #73)
> Sorry, you were right :)
> Could you file a new bug about this issue?

Filed bug 723322.

Comment 75

[paulf]

after i set gfx.canvas.azure.enabled to true the about:memory page no longer works. we want a bug for this ?

Comment 76

[Stefan Fleiter (:sfleiter)]

(In reply to paulf from comment #75)
> after i set gfx.canvas.azure.enabled to true the about:memory page no longer
> works. we want a bug for this ?

Not reproducible over here:
Mozilla/5.0 (X11; Linux x86_64; rv:13.0a1) Gecko/20120205 Firefox/13.0a1

What are the exact and minimal steps to reproduce?
Does this problem occur with a new/fresh profile?

Comment 77

[paulf]

To reproduce i enabled gfx.azure.enabled and restarted browser. 
i have about:memory open and refreshing it works fine.
i then set gfx.canvas.azure.enabled to true. refreshing the about:memory tab works. 
close the about:memory tab and open a fresh one - now its blank.

Comment 78

[Stefan Fleiter (:sfleiter)]

(In reply to paulf from comment #77)
> To reproduce i enabled gfx.azure.enabled and restarted browser. 
> i have about:memory open and refreshing it works fine.
> i then set gfx.canvas.azure.enabled to true. refreshing the about:memory tab
> works. 
> close the about:memory tab and open a fresh one - now its blank.

Thanks paulf, I can reproduce this now, but needed several tries.
Care to create a new bug blocking this one?

Comment 79

[Constantine]

Now, after crashes have been fixed could you make gfx.content.azure.enabled working on Linux? As I understand there is no way to enable Azure for drawing all content at this moment (gfx.content.azure.enabled doesn't work), but I'd like to test it. Do we need a separate bug for it and are there any problems to do this now?

Comment 80

[George Wright (:gw280) (needinfo me!)]

I have an experimental branch of mozilla-central with skia content rendering in Linux:

https://github.com/gw280/mozilla-central/commits/gwright/skia_content

Comment 81

[Constantine]

(In reply to George Wright (:gw280) from comment #80)
> I have an experimental branch of mozilla-central with skia content rendering
> in Linux:
> 
> https://github.com/gw280/mozilla-central/commits/gwright/skia_content

Thank you for your work and this branch. It compiles and runs normally for me. Other thing is that enabling Skia for content rendering leads to 2 problems:
1. Skia rendering doesn't work together with hardware layer acceleration (when I enabled it I got a black screen).
2. (Most important) Font rendering is still ugly. With gfx.content.azure.enabled all fonts look monospace, there is no unicode support (all pages become written in unknown symbols and I cannot type anything in Russian). I'm not a programmer but I think some component of font rendering engine is missing (freetype or something else).
I know it isn't appropriate place for filing bugs against custom branches, but I use it only to prove the idea that now Azure and Skia being libraries designed for general-purpose drawing need wider tests. <canvas> element seems to work practically on every page (and switching to Azure is a great improvement of performance) but only a few webpages have text inside <canvas>, and, in general, canvas is not so wide-spreaded among Web now to involve a lot of testers of the new graphical engine. And adding an option for content rendering into m-c may help to involve them and fix problems much quicker because it's much closer to daily browsing. Unfortunately, I don't know how much work it must be but anyway it would be fine.

Comment 82

[George Wright (:gw280) (needinfo me!)]

(In reply to konstartyom from comment #81)
> (In reply to George Wright (:gw280) from comment #80)
> > I have an experimental branch of mozilla-central with skia content rendering
> > in Linux:
> > 
> > https://github.com/gw280/mozilla-central/commits/gwright/skia_content
> 
> Thank you for your work and this branch. It compiles and runs normally for
> me. Other thing is that enabling Skia for content rendering leads to 2
> problems:
> 1. Skia rendering doesn't work together with hardware layer acceleration
> (when I enabled it I got a black screen).
> 2. (Most important) Font rendering is still ugly. With
> gfx.content.azure.enabled all fonts look monospace, there is no unicode
> support (all pages become written in unknown symbols and I cannot type
> anything in Russian). I'm not a programmer but I think some component of
> font rendering engine is missing (freetype or something else).
> I know it isn't appropriate place for filing bugs against custom branches,
> but I use it only to prove the idea that now Azure and Skia being libraries
> designed for general-purpose drawing need wider tests. <canvas> element
> seems to work practically on every page (and switching to Azure is a great
> improvement of performance) but only a few webpages have text inside
> <canvas>, and, in general, canvas is not so wide-spreaded among Web now to
> involve a lot of testers of the new graphical engine. And adding an option
> for content rendering into m-c may help to involve them and fix problems
> much quicker because it's much closer to daily browsing. Unfortunately, I
> don't know how much work it must be but anyway it would be fine.

Thanks for the feedback. These are currently known issues, but unfortunately the Skia/Linux work has been put on the backburner for a while. I will definitely try to get round to looking at it soon though!

Comment 83

[Constantine]

Since pdf.js has been landed onto m-c (see Bug 714712) canvas is used for rendering pdf files which often contain text. Unfortunately, I still see these awful fonts if Skia is enabled, therefore it isn't usable for things which are most common. Of course, I can open pdf in Evince, but I think appearing of such feature adds great possibilities for testing Skia backend.

Comment 84

[George Wright (:gw280) (needinfo me!)]

I'm actively working on fonts in Linux.