[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#435374: marked as done (libqt4-core: qt4 loose performance by using "direct rendering" that falls back on sw)

Your message dated Sat, 11 Jan 2014 18:37:04 -0300
with message-id <2560181.zLKh8V2t7L@luna>
and subject line Closing per user request
has caused the Debian Bug report #435374,
regarding libqt4-core: qt4 loose performance by using "direct rendering" that falls back on sw
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
435374: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=435374
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message --- 
Package: libqt4-core
Version: 4.3.0-4
Severity: normal


I have not seen the bug myself, but I report it on behalf of
lyx development.  The LyX word processor uses qt4 as its interface.

Some users have seen a large slowdown, it turned out that they 
had machines where DRI was implemented by a software fallback.
Commenting out "dri" from the "Module" section speeded things
up tremendously.  This because disabling DRI completely means that
qt4 uses normal X11 instead of direct rendering.

I understand that using direct rendering may be a nice speedup
when hardware acceleration is in use. But is very slow
when there is no smart hardware so the implementation fall
back on software.

Suggested fix:
Surely qt4 does a test to see if DRI is available, and fall back
on X11 when DRI isn't present.  (Otherwise, qt4 wouldn't work
at all on a machine without DRI.)

The fix then, is to also check that DRI is backed by hardware
before trying to use it.  This can't be hard to check.
Look at "glxinfo", it will print 
"direct rendering: yes/no" depending on hardware acceleration.
It will print "no" even when DRI is available but backed by software
only.


Please, just do the same check that glxinfo does, and don't
try to use slow software DRI interfaces.  This will be a nice
speedup for many qt4 apps running on machines without DRI hardware.
There are lots of such machines, especially when we get outside
the x86 world which debian supports so well.  And the fix
is rather simple too. :-)


-- System Information:
Debian Release: lenny/sid
  APT prefers testing
  APT policy: (900, 'testing'), (800, 'unstable'), (800, 'stable'), (700, 'experimental')
Architecture: i386 (i686)

Kernel: Linux 2.6.22-rc6-cfs-v18
Locale: LANG=nb_NO.UTF-8, LC_CTYPE=nb_NO.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash

Versions of packages libqt4-core depends on:
ii  libc6                   2.6-2            GNU C Library: Shared libraries
ii  libdbus-1-3             1.1.1-3          simple interprocess messaging syst
ii  libfontconfig1          2.4.2-1.2        generic font configuration library
ii  libgcc1                 1:4.2-20070712-1 GCC support library
ii  libglib2.0-0            2.12.13-1        The GLib library of C routines
ii  libstdc++6              4.2-20070712-1   The GNU Standard C++ Library v3
ii  zlib1g                  1:1.2.3.3.dfsg-5 compression library - runtime

libqt4-core recommends no packages.

-- debconf-show failed

--- End Message ---
--- Begin Message --- 
Version: 4:4.8.2+dfsg-11

Closing at user's request. I'm using Wheezy's version which I think is good 
enough.

-- 
El futuro es WIN95.... A no ser que hagamos algo a tiempo.

Lisandro Damián Nicanor Pérez Meyer
http://perezmeyer.com.ar/
http://perezmeyer.blogspot.com/

Attachment: signature.asc
Description: This is a digitally signed message part.


--- End Message ---
Reply to: