Extreme display corruption

[Kishore]

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.

-- 
Cheers!
Kishore