Extreme display corruption
Aleix Pol
aleixpol at kde.org
Tue Sep 15 19:19:45 UTC 2009
On Tue, Sep 15, 2009 at 12:11 PM, Milian Wolff <mail at milianw.de> wrote:
> 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
>
> _______________________________________________
> KDevelop-devel mailing list
> KDevelop-devel at kdevelop.org
> https://barney.cs.uni-potsdam.de/mailman/listinfo/kdevelop-devel
>
I've been using intel and I haven't had any problem with intel with any
driver+kernel combination using raster, so it's definitely something else.
I'm working with 2.6.31 and intel 2.8 works like a charm now :D
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20090915/3109acf3/attachment.html>
More information about the KDevelop-devel
mailing list