Open Bug 32736 Opened 24 years ago Updated 2 years ago

Use X11 shm code to speed up blending

Categories

(Core :: Web Painting, defect, P3)

Product:
Core
Component:
Web Painting
Platform:
x86
Linux
Type:
defect

Tracking

()

Milestone:
Future

People

(Reporter: adam, Unassigned)

References

(
URL
)

Details

(Keywords: perf)

Attachments

(1 file, 1 obsolete file)

even more SHM usage
30.68 KB, patch
Details | Diff | Splinter Review 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; N; Linux 2.2.14 i686; en-US; m14)
BuildID:    2000030708 (CVS, march 21st)


If I configure with --enable-x11-shm and visit a page which uses
the opacity style then Mozilla crashes with a GTK error like
this:
Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 18726 error_code 8 request_code 129 minor_code 4



Reproducible: Always
Steps to Reproduce:
1. configure and compile with --enable-x11-shm (define USE_SHM)
2. visit a page which uses opacity, e.g. demo10



Actual Results:  mozilla crashed with

Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 18726 error_code 8 request_code 129 minor_code 4




Expected Results:  browser should not have crashed, opacity effect should have
worked.





xfree86 v3.3.5
cvs-gtk-1.2.latest



Aha, this still happens with pages using semi-opacity even with
--disable-x11-shm, but not as quickly, and not at all with demo10
AFAICS.

--Adam
Target Milestone: ---
reassigning to pavlov for triage.
Assignee: trudelle → pavlov
can you give me a page that does crash with --disable-x11-shm ?
Target Milestone: --- → M16
Yes, Master Pavlov... yes, I can.



http://www.ygv50.dial.pipex.com/moz1/






the view manager is calling blend on a rect with a 0 width and/or height.  this
will cause bad things to happen.
Assignee: pavlov → beard
Component: XP Toolkit/Widgets → Views
Depends on: 33219
nsViewManager2.cpp v1.18 now checks for 0x0 blending rect.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Still crashes with --enable-x11-shm and above URL
(not retested with --disable-x11-shm yet).

Gdk-ERROR **: BadMatch (invalid parameter attributes)
  serial 1355 error_code 8 request_code 129 minor_code 4

Fresh from CVS (2000-03-29 ~13:00 BST).

After a cursory search I can't find an X request matching
code 129 -- perhaps it belongs to an extention.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
ok, i'm seeing this now.  it is my bug again.. argh.  Are you running gtk 1.2.7
with xfree 4 by any chance?
Assignee: beard → pavlov
Status: REOPENED → NEW
Keywords: crash







Hi.

I am running GTK 1.2.7, and XFree86 3.3.5


Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17
Blocks: 26860
I have forefully disabled the use of enable-x11-shm.. i.e. you turn it on but it
isn't really on.  I'm going to mark this bug as fixed but file a new bug that
X11 shm stuff doesn't work anymore.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
better yet, i'm going to just change the title
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Summary: gtkfe crashes with --enable-x11-shm and page with opacity → X11 shm code does not work anymore
Status: REOPENED → ASSIGNED
moving to m18
Target Milestone: M17 → M18
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
Is this working yet?  =)

Getting this to work should speed up image drawing and other such things a bit
on linux.  It should be fairly easy to fix since all of the work I did a long
time ago.
Keywords: nsbeta3, perf
*** Bug 26860 has been marked as a duplicate of this bug. ***
No longer blocks: 26860
nsbeta3+, insofar as it will fix Top Performance Issues like UI sluggishness.
Whiteboard: [nsbeta3+]
Target Milestone: M21 → M18
Also, configure should be changed so that --enable-x11-shm is the default, 
rather than --disable-x11-shm.
I do not believe this code to have provided any real speedup to the product. 
therefore, I am marking this bug won't fix.  I have removed the code from the
product.  Since the code only kicked in when blending occurs, which is rare, and
fixing it was non-trivial, I don't see any reason to spend time fixing this.  If
I thought it would be a performance win, I would, but my tests have not shown it
to be one.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
er
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WONTFIX
resolving
I saw significant speedups under Quantify when this code used to work.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
changing summary, futuring
Status: REOPENED → ASSIGNED
Keywords: nsbeta3
Summary: X11 shm code does not work anymore → Use X11 shm code to speed up blending
Whiteboard: [nsbeta3+]
Target Milestone: M18 → Future
Keywords: crash
Code that uses USE_SHM has gone from the tree,
hasn't it?

Please note that the fix for bug 110804 might have
solved the problem that was originally inhibiting the
use of shm.

Since this bug and bug 110804 related to completely separate code I do not 
understand how the fix there might help here.

See comment #5.  AFAICS your fix for bug 110804 removes
one (the final?) case in which mozilla might accidentally try
to fetch a null-rect.




I see. Getting pixels from the server is messy and it took me a while
to figure it out. I found that the calls are very intolerant: I can
accept a call that returns an error on bad parameters but I dislike a
call that internally calls exit. Very rude behavior.

That said, the shm code should have been fixed instead of scrapped if this 
was the only issue.


blizzard and tor CC:'d you because this seems
like something you'd have insights and opinions on...

I roughly (re-)implemented XShmGetImage() support for testing and was surprised
to find that it works seemingly-flawlessly.
This patch roughly implements MIT-SHM image reads from server to client.  I
haven't attempted to bulletproof it but curiously I can't make it misrender
despite not putting effort into verifying the x/y/width/height stuff or
over-fetching of window area (possibly viewmanager sanitizes all of that now).

(The scaled[56] stuff in the patch is unrelated but harmless playing around
with trying to make gcc < 3 generate better code with its comparatively lame
alias analysis.)

It doesn't attempt to check whether you're running locally or not, plus it
assumes that the extension is available on the build machine (for headers) and
server (for runtime).

However, for me it doesn't run appreciably faster than the existing non-SHM
code.  You're welcome to try it for yourself; YMMV.
Pav is gone, right?  Can I reassign to nobody@mozilla.org?

If there is not much speed gain perhaps we should consider closing this WONTFIX
It's not a significant win for _me_, that's all I can say.  It may or may not be
a significant win on a different X server, graphics card, or architecture.  The
patch is up there for anyone who wants to see if it's good for them.
Assignee: pavlov → nobody
Status: ASSIGNED → NEW
dmose, you saw significant speedups with the old MIT-SHM support according to
comment 23.  Would you mind re-testing to see if this is still the case?

It's possible that my basic implementation of shm usage is inefficient; my raw X
is getting rusty.  I don't see an obvious problem though.

hey, i still work here, just not much on mozilla these days ;-)
Pav!  You're alive!

Oh well, I assume you don't want the bug anyway. :)
Oh, that's interesting.  The tests I performed that I thought were exercising
this code path, aren't exercising this code path.  I'll look into it some more.

Okay, using SHM is roughly twice as fast for me when compositing alpha images.

I'm just patching up the blending path I missed (the one that antialiased fonts
use), and I'll submit the changes.

I can't easily retest, as the environment I was using for that was Solaris and
Quantify, and now that I'm no longer at Netscape, I don't have access to it. 
Additionally, I'm stuck on a windows box at the moment.  If somebody wanted to
attack this with jprof or maybe the MOZ_TIMELINE stuff that might be a good
strategy.
I've more-or-less added SHM usage to the font-blending code too, though the wins
there don't seem particularly noticable to the eye (probably the insane number
of round-trips and the XImage set-up involved for lots of little serialized
fetches and puts greatly outweigh the cost of actually transferring the data).

I'll attach an updated patch soon.

While I was in the gtk/x11 aa-font code I noticed that we unconditionally use
XPutImage to draw the (great number of) composited area(s), where I think we
could usually use XShmPutImage.  I'm still trying to get that to work
(mysterious failure).


This new patch uses shared memory gets/puts a whole lot more, in fact just
about everywhere that it's feasible.

It doesn't seem appreciably faster than the last version of the patch, for me. 
I think this is largely because it's a naive approach to converting non-shm
ximage manipulation to shm which causes rather a lot of shmimage/segment churn
and (synchronous?) server round-trips.

This is probably the last stab I'll make at SHM hackery.  I hope it's useful
for anyone else who wishes to continue the exploration.
Attachment #112080 - Attachment is obsolete: true
Looks like you are making good progress.

I notice this does not test if shared memory is available. Since alpha blending 
moves so much data it is reasonable to limit it to only work on systems where 
the frame buffer is local. So my only question is whether we know if shm is 
available on the majority of systems that might use this?
You're right that it doesn't do decent run-time checking for SHM availability. 
It's just sort of a hack to see how much potential win there really is in using
shared-memory transfers.

I haven't looked at this code for a while (though I've been running it for
several months now), but it does seem to have a fall-back to plain XImages when
something goes wrong with the SHM image creation -- don't remember if I've
tested this path.  It's not the ideal time to be checking for this time, at
image creation time -- at initialization time one can ask X whether the
extension is available, for example (and IIRC GDK offers a call, something like
gdk_get_shm(), to see whether GDK itself is actually using SHM, which is a
really good clue).

Again, this patch isn't really code to roll-out, just a good jumping-point for
anyone wanting to evaluate possible MITSHM usage wins (my time on this matter is
just about used up).
Roc, don't you have some bugs (about moving blending into platform gfx?) that
could benefit from this?
Yeah, but I think the big win comes from doing the whole blend on the server (or
via some non-X hardware acceleration mechanism such as OpenGL) so I'm not
terribly interested in reviving this SHM work specifically. Besides which I know
nothing about it.
QA Contact: jrgmorrison → layout.view-rendering
As far as I know this should really be closed - blending is done by using xrender through cairo on X11 based platforms.

So although SHM is useful, its not required for scaling anymore, scaling can be done hw accelerated finally =)
Component: Layout: View Rendering → Layout: Web Painting
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: