Extreme display corruption

[Milian Wolff]

Kishore, 15.09.2009:
> On Tuesday 15 Sep 2009 3:34:25 pm Milian Wolff wrote:
> > Kishore wrote:
> > > On Monday 14 Sep 2009 7:56:30 pm Kishore wrote:
> > >> On Monday 14 Sep 2009 7:14:16 pm Andreas Pakulat wrote:
> > >>> On 14.09.09 16:26:36, Nikos Chantziaras wrote:
> > >>>> On 09/14/2009 03:41 PM, Andreas Pakulat wrote:
> > >>>>> On 14.09.09 15:26:52, Nikos Chantziaras wrote:
> > >>>>>> On 09/14/2009 02:20 PM, Milian Wolff wrote:
> > >>>>>>> Nikos Chantziaras, 14.09.2009:
> > >>>>>
> > >>>>> And with "native" KDevelop is simply
> > >>>>> unusable.
> > >>>>
> > >>>> What exactly do you mean?  It seems to work great for me.
> > >>>
> > >>> It means that with the extensive highlighting we do for C++ scrolling
> > >>> and editing in katepart are horribly slow. We've found that factors
> > >>> influencing this include compositing-effects as well as general PC
> > >>> power.
> > >>>
> > >>> Or try a very long line thats dynamically wrapped inside the editor,
> > >>> thats also very slow to edit with native engine, but really fast with
> > >>> raster.
> > >>>
> > >>>>>> With all things considered, I don't think KDevelop should use
> > >>>>>> raster on it's own; IMHO that's a choice the user should make;
> > >>>>>> apps should follow the default unless the user says otherwise.
> > >>>>>
> > >>>>> Except if the default makes the app in question unusable. We want
> > >>>>> to provide a nice experience from the start, without the User
> > >>>>> having to dig up some obscure cmdline option.
> > >>>>
> > >>>> This way we end up with each app circumventing defaults.  Imagine if
> > >>>> each app would do that.  Users would have to configure each and
> > >>>> every one separately and we're back to the 1980's.  Surely I'm not
> > >>>> the only one who sees something wrong about this approach?  On most
> > >>>> systems, Qt is not configured with raster as default, and there's a
> > >>>> reason for that.
> > >>>
> > >>> How do you measure "most systems"? I've got 3 at hand and all of them
> > >>> use raster by default. There are in fact only few desktop apps that
> > >>> cannot use raster at all because they rely on certain implementation
> > >>> details of native and the KDE apps among them apply the same code we
> > >>> do to force their app to use native instead of raster - ignoring my
> > >>> configured Qt default ;)
> > >>>
> > >>>> In any event, I don't feel too strongly about it, since now I know
> > >>>> how to fix it.  Just mentioning that this might bite lots of people
> > >>>> and it might be a good idea to make this configurable in KDevelop
> > >>>> and using Qt's default by default.
> > >>>
> > >>> It already is configurable by using the cmdline switch supplied by
> > >>> Qt.
> > >>
> > >> Thanks for this discussion. On my Samsung NC10 (Netbook with intel
> > >>  graphics) KDevelop started to feel really slow the last couple of
> > >> weeks. After this discussion, i wanted to give it a try and launched
> > >> kdevelop with - graphicssystem native. It is so much faster!
> > >> Relaunching without that option make is slow again!
> > >>
> > >> May be reconsider that decision?
> > >
> > > For more information, this netbook is running Kubuntu Karmic with intel
> > > graphics driver version 2.8.1 using xserver-xorg version 1.6.3
> > > Qt: 4.5.2
> > > KDE: 4.3.1 (KDE 4.3.1)
> > > KDevelop: 3.9.95 (using KDevPlatform 0.9.95) (compiled from sources)
> >
> > What kind of intel is that? I have one myself at home and will give you
> > my setup later on. Though I have still Jaunty, but a lot of backported
> > intel drivers.
> >
> > I'll get back to you later today.
> 
> GMA 950.
> 

$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 
Integrated Graphics Controller (rev 0c)

libdrm-intel1:
Version: 2.4.13~git-0ubuntu0tormod~jaunty
xserver-xorg-video-intel:
Version: 2:2.8.99.901~git20090914.c2abfa8e-0ubuntu0tormod~jaunty
kernel:
2.6.30-020630-generic
Qt version 4.5.2

And I have no problem with -graphicssystem raster

Maybe a regression in karmic?

-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090915/e6ffd29c/attachment.sig>