all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Assertion failes in w32uniscribe.c
@ 2008-04-03 14:41 Juanma Barranquero
  2008-04-03 15:06 ` Jason Rumney
  0 siblings, 1 reply; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-03 14:41 UTC (permalink / raw)
  To: Jason Rumney, Emacs Devel

emacs -q
C-h H

=>

w32uniscribe.c:671: Emacs fatal error: assertion failed: CONSP((rest))

Breakpoint 1, w32_abort () at w32fns.c:9380
9380      button = MessageBox (NULL,
(gdb) backtrace
#0  w32_abort () at w32fns.c:9380
#1  0x0101f3bb in die (msg=0x143b2d8 "assertion failed:
CONSP((rest))", file=0x143aab0 "w32uniscribe.c", line=671)
    at alloc.c:6210
#2  0x01219b7c in uniscribe_check_otf (font=0x82d39c,
otf_spec=19767685) at w32uniscribe.c:671
#3  0x012136ef in add_font_entity_to_list@16 (logical_font=0x82d39c,
physical_font=0x82d1b4, font_type=4,
    lParam=8574288) at w32font.c:1243
#4  0x77f1b961 in GDI32!CreateFontA () from C:\WINDOWS\system32\gdi32.dll
#5  0x0082d39c in ?? ()
#6  0x0082d1b4 in ?? ()
#7  0x00000004 in ?? ()
#8  0x0082d550 in ?? ()
#9  0x00000001 in ?? ()
#10 0x0086efb8 in ?? ()
#11 0x00000000 in ?? ()

Lisp Backtrace:
"font-at" (0x82d8f4)
"auto-compose-chars" (0x82db20)


-- 
 Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-03 14:41 Assertion failes in w32uniscribe.c Juanma Barranquero
@ 2008-04-03 15:06 ` Jason Rumney
  2008-04-03 17:22   ` Juanma Barranquero
  0 siblings, 1 reply; 23+ messages in thread
From: Jason Rumney @ 2008-04-03 15:06 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

Juanma Barranquero wrote:
> w32uniscribe.c:671: Emacs fatal error: assertion failed: CONSP((rest))
>   

I'll add code to avoid the assertion, but can you debug and see where 
this bogus font spec is coming from?





^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-03 15:06 ` Jason Rumney
@ 2008-04-03 17:22   ` Juanma Barranquero
  2008-04-04  8:14     ` Jason Rumney
  0 siblings, 1 reply; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-03 17:22 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

On Thu, Apr 3, 2008 at 5:06 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  I'll add code to avoid the assertion

In

+  /* Check the spec is in the right format.  */
+  if (!CONSP (otf_spec) || Flength (val) < 3)
+    return 0;
+

I suppose it's really Flength (otf_spec), isn't it?


> but can you debug and see where this
> bogus font spec is coming from?

Yes.


    Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-03 17:22   ` Juanma Barranquero
@ 2008-04-04  8:14     ` Jason Rumney
  2008-04-04  9:17       ` Juanma Barranquero
  2008-04-04  9:35       ` Juanma Barranquero
  0 siblings, 2 replies; 23+ messages in thread
From: Jason Rumney @ 2008-04-04  8:14 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

Juanma Barranquero wrote:
> I suppose it's really Flength (otf_spec), isn't it?
>   

Fixed.

>> but can you debug and see where this
>> bogus font spec is coming from?
>>     
>
> Yes.
>   

To clarify what I mean, the following commands would give a lot of 
useful information:

(with old code, after the crash):
frame 2
pp otf_spec

(with new code):
break w32uniscribe.c:569
break w32uniscribe.c:618
run -q
pp otf_spec

    (gdb) backtrace
    #0  w32_abort () at w32fns.c:9380
    #1  0x0101f3bb in die (msg=0x143b2d8 "assertion failed:
    CONSP((rest))", file=0x143aab0 "w32uniscribe.c", line=671)
        at alloc.c:6210
    #2  0x01219b7c in uniscribe_check_otf (font=0x82d39c,
    otf_spec=19767685) at w32uniscribe.c:671
      






^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04  8:14     ` Jason Rumney
@ 2008-04-04  9:17       ` Juanma Barranquero
  2008-04-04  9:42         ` Jason Rumney
  2008-04-04  9:35       ` Juanma Barranquero
  1 sibling, 1 reply; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-04  9:17 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:

>  (with old code, after the crash):
>  frame 2
>  pp otf_spec
>
>  (with new code):
>  break w32uniscribe.c:569
>  break w32uniscribe.c:618
>  run -q
>  pp otf_spec

Are you assuming that after adding this:

  /* Check the spec is in the right format.  */
  if (!CONSP (otf_spec) || Flength (otf_spec) < 3)
    return 0;

it does not crash? Because it still does.

   Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04  8:14     ` Jason Rumney
  2008-04-04  9:17       ` Juanma Barranquero
@ 2008-04-04  9:35       ` Juanma Barranquero
  2008-04-04 10:29         ` Jason Rumney
  1 sibling, 1 reply; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-04  9:35 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:

With new code:

--------------------------------------------------------------------------------
(gdb) break w32uniscribe.c:569
Breakpoint 3 at 0x1218e56: file w32uniscribe.c, line 569.
(gdb) break w32uniscribe.c:618
Breakpoint 4 at 0x1219166: file w32uniscribe.c, line 618.
(gdb) run -q
Starting program: C:\emacs\trunk\src/..\emacs.exe -q
[New thread 1560.0x720]
[New thread 1560.0x18c]

Breakpoint 3, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:572
572       script = XCAR (otf_spec);
(gdb) pp otf_spec
(gujr nil (rphf))
(gdb) continue
Continuing.

Breakpoint 4, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:621
621           OTF_INT16_VAL (tbl, 4, &scriptlist_table);
(gdb) pp otf_spec
0
(gdb) continue
Continuing.

w32uniscribe.c:679: Emacs fatal error: assertion failed: CONSP((rest))

Breakpoint 1, w32_abort () at w32fns.c:9380
9380      button = MessageBox (NULL,
(gdb) frame 2
#2  0x012198d2 in uniscribe_check_otf (font=0x82d39c,
otf_spec=19767413) at w32uniscribe.c:679
679           for (feature = XCAR (rest); CONSP (rest); feature = XCAR (rest))
(gdb) pp otf_spec
nil
(gdb)
--------------------------------------------------------------------------------

My Emacs is compiled with optimization, -DENABLE_CHECKING=1 and
-fno-crossjumping. I can do a non-optimized build, if necessary.

Perhaps irrelevant, but the crash is in Windows XP Pro, usp10.dll's
version is 1.601.5022.8, and gcc is "gcc (GCC) 4.2.1-sjlj
(mingw32-2)".

 Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04  9:17       ` Juanma Barranquero
@ 2008-04-04  9:42         ` Jason Rumney
  0 siblings, 0 replies; 23+ messages in thread
From: Jason Rumney @ 2008-04-04  9:42 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

Juanma Barranquero wrote:
> On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
>   
>>  (with old code, after the crash):
>>  frame 2
>>  pp otf_spec
>>
>>  (with new code):
>>  break w32uniscribe.c:569
>>  break w32uniscribe.c:618
>>  run -q
>>  pp otf_spec
>>     
>
> Are you assuming that after adding this:
>
>   /* Check the spec is in the right format.  */
>   if (!CONSP (otf_spec) || Flength (otf_spec) < 3)
>     return 0;
>
> it does not crash? Because it still does.
>   

I was assuming that the other part of the change would be what prevented 
this particular crash, since it was already getting past the point above:

      /* If features is not a cons, this font spec is messed up.  */
      if (!CONSP (features[i]))
        goto no_support;





^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04  9:35       ` Juanma Barranquero
@ 2008-04-04 10:29         ` Jason Rumney
  2008-04-04 11:40           ` Juanma Barranquero
  2008-04-04 12:54           ` Juanma Barranquero
  0 siblings, 2 replies; 23+ messages in thread
From: Jason Rumney @ 2008-04-04 10:29 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

Juanma Barranquero wrote:
> On Fri, Apr 4, 2008 at 10:14 AM, Jason Rumney <jasonr@gnu.org> wrote:
>
> With new code:
>   
You may need to compile without optimizations, to get the breakpoints on 
the actual goto statements instead of the following line.


> (gdb) break w32uniscribe.c:569
> Breakpoint 3, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
> at w32uniscribe.c:572
> 572       script = XCAR (otf_spec);
>   

> (gdb) pp otf_spec
> (gujr nil (rphf))
>   

That looks OK.

> Breakpoint 4, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
> at w32uniscribe.c:621
> 621           OTF_INT16_VAL (tbl, 4, &scriptlist_table);
> (gdb) pp otf_spec
>   
> 0
>   

That doesn't, but maybe optimizations are interfering, as otf_spec is 
not used later in the function, so it may have been optimized away already
What about "pp features[i]" and "print i"






^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 10:29         ` Jason Rumney
@ 2008-04-04 11:40           ` Juanma Barranquero
  2008-04-04 11:44             ` Juanma Barranquero
  2008-04-04 12:54           ` Juanma Barranquero
  1 sibling, 1 reply; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-04 11:40 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

On Fri, Apr 4, 2008 at 12:29 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  What about "pp features[i]" and "print i"

Breakpoint 3, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:572
572       script = XCAR (otf_spec);
(gdb) pp features[i]
0
(gdb) print i
$1 = 19767413
(gdb) continue
Continuing.

Breakpoint 4, uniscribe_check_otf (font=0x82d39c, otf_spec=19767413)
at w32uniscribe.c:621
621           OTF_INT16_VAL (tbl, 4, &scriptlist_table);
(gdb) pp features[i]
(rphf)
(gdb) print i
$2 = 0
(gdb) continue
Continuing.

w32uniscribe.c:679: Emacs fatal error: assertion failed: CONSP((rest))

Breakpoint 1, w32_abort () at w32fns.c:9380
9380      button = MessageBox (NULL,
(gdb) frame 2
#2  0x012198d2 in uniscribe_check_otf (font=0x82d39c,
otf_spec=19767413) at w32uniscribe.c:679
679           for (feature = XCAR (rest); CONSP (rest); feature = XCAR (rest))
(gdb) pp features[i]
Cannot access memory at address 0x6c27118
(gdb) print i
$3 = 26208257
(gdb)

 Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 11:40           ` Juanma Barranquero
@ 2008-04-04 11:44             ` Juanma Barranquero
  0 siblings, 0 replies; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-04 11:44 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

Additional info: the assertion triggers when displaying bengali,
gujarati, hindi, kannada, khmer, lao, malayalam, oriya, sinhala,
tamil, tegulu or tibetan.

Note that the usp10.dll I have, 1.601.5022.8, comes from the "Sinhala
Enabling Pack for XP 0.42" (see
http://en.wikipedia.org/wiki/Uniscribe).

 Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 10:29         ` Jason Rumney
  2008-04-04 11:40           ` Juanma Barranquero
@ 2008-04-04 12:54           ` Juanma Barranquero
  2008-04-04 17:02             ` Lennart Borgman (gmail)
  2008-04-06  1:14             ` Jason Rumney
  1 sibling, 2 replies; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-04 12:54 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

OK, it is working now. Thanks.

It is still slow, though. From  "emacs -Q -f view-hello-file" to
actually see etc/HELLO, about 8-10 seconds, or three times slower than
the same operation using --disable-font-backend.

 Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 12:54           ` Juanma Barranquero
@ 2008-04-04 17:02             ` Lennart Borgman (gmail)
  2008-04-04 17:50               ` Claus
  2008-04-04 19:32               ` Óscar Fuentes
  2008-04-06  1:14             ` Jason Rumney
  1 sibling, 2 replies; 23+ messages in thread
From: Lennart Borgman (gmail) @ 2008-04-04 17:02 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel, Jason Rumney

Juanma Barranquero wrote:
> OK, it is working now. Thanks.
> 
> It is still slow, though. From  "emacs -Q -f view-hello-file" to
> actually see etc/HELLO, about 8-10 seconds, or three times slower than
> the same operation using --disable-font-backend.

I am still using --disable-font-backend because without it there has 
been some very annoying screen blinking. Has anyone else seen this?

Another strange things I have seen the last days is that sometimes the 
welcome screen is shown without any colors and without the image. Next 
time I try it works as it should. Does not that look like a missing 
initialization somewhere?

But please notice that this is with my slightly patched version (v 23, 
2008-04-03).




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 17:02             ` Lennart Borgman (gmail)
@ 2008-04-04 17:50               ` Claus
  2008-04-04 20:34                 ` Jason Rumney
  2008-04-04 19:32               ` Óscar Fuentes
  1 sibling, 1 reply; 23+ messages in thread
From: Claus @ 2008-04-04 17:50 UTC (permalink / raw)
  To: Lennart Borgman (gmail); +Cc: Juanma Barranquero, Jason Rumney, Emacs Devel

>  I am still using --disable-font-backend because without it there has been
> some very annoying screen blinking. Has anyone else seen this?

Confirmed. Lot's of blinking, especially when the screen is split (C-x
2). It looks like for each keystroke both buffers are completely
redisplayed (or parsed... or re-fontified... hard to tell the
difference).

Whatever it is, it causes lag / slowdown during typing.

Thus, I see myself using C-x 1 all the time to enhance performance a bit.

GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6000) of 2008-03-23 on WindowsVista

Claus


On Fri, Apr 4, 2008 at 7:02 PM, Lennart Borgman (gmail)
<lennart.borgman@gmail.com> wrote:
>
> Juanma Barranquero wrote:
>
> > OK, it is working now. Thanks.
> >
> > It is still slow, though. From  "emacs -Q -f view-hello-file" to
> > actually see etc/HELLO, about 8-10 seconds, or three times slower than
> > the same operation using --disable-font-backend.
> >
>
>  I am still using --disable-font-backend because without it there has been
> some very annoying screen blinking. Has anyone else seen this?
>
>  Another strange things I have seen the last days is that sometimes the
> welcome screen is shown without any colors and without the image. Next time
> I try it works as it should. Does not that look like a missing
> initialization somewhere?
>
>  But please notice that this is with my slightly patched version (v 23,
> 2008-04-03).
>
>
>



--

Mit freundlichem Gruß,
Claus Klingberg




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 17:02             ` Lennart Borgman (gmail)
  2008-04-04 17:50               ` Claus
@ 2008-04-04 19:32               ` Óscar Fuentes
  1 sibling, 0 replies; 23+ messages in thread
From: Óscar Fuentes @ 2008-04-04 19:32 UTC (permalink / raw)
  To: emacs-devel

"Lennart Borgman (gmail)" <lennart.borgman@gmail.com> writes:

> I am still using --disable-font-backend because without it there has
> been some very annoying screen blinking. Has anyone else seen this?

With the new font backend, redisplay is so slow that Emacs is unusable
on an AMD Athlon 550 MHz (Windows2kSP4), and takes a good share of CPU
on a 2 GHz Pentium M (XPSP2).

The effect is more serious on certain applications (Gnus, ERC) although
it is bad enough while editing or viewing C/C++/Elisp source files.

For now, I'll use --disable-font-backend.

[snip]

-- 
Oscar





^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 17:50               ` Claus
@ 2008-04-04 20:34                 ` Jason Rumney
  2008-04-04 22:53                   ` Lennart Borgman (gmail)
  0 siblings, 1 reply; 23+ messages in thread
From: Jason Rumney @ 2008-04-04 20:34 UTC (permalink / raw)
  To: Claus; +Cc: Juanma Barranquero, Lennart Borgman (gmail), Emacs Devel

Claus wrote:
> Confirmed. Lot's of blinking, especially when the screen is split (C-x
> 2). It looks like for each keystroke both buffers are completely
> redisplayed (or parsed... or re-fontified... hard to tell the
> difference).
>
> GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6000) of 2008-03-23 on WindowsVista
>
> On Fri, Apr 4, 2008 at 7:02 PM, Lennart Borgman (gmail)
> <lennart.borgman@gmail.com> wrote:
>   
>>     
>>  But please notice that this is with my slightly patched version (v 23,
>> 2008-04-03).
>>     

Can you both please try the latest version. I fixed a bug yesterday with 
the text extents, which could explain the described behaviour.
It does not seem to flicker for me now, though admittedly I have seen it 
in the past.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 20:34                 ` Jason Rumney
@ 2008-04-04 22:53                   ` Lennart Borgman (gmail)
  0 siblings, 0 replies; 23+ messages in thread
From: Lennart Borgman (gmail) @ 2008-04-04 22:53 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Juanma Barranquero, Claus, Emacs Devel

Jason Rumney wrote:
> Claus wrote:
>> Confirmed. Lot's of blinking, especially when the screen is split (C-x
>> 2). It looks like for each keystroke both buffers are completely
>> redisplayed (or parsed... or re-fontified... hard to tell the
>> difference).
>>
>> GNU Emacs 23.0.60.1 (i386-mingw-nt6.0.6000) of 2008-03-23 on WindowsVista
>>
>> On Fri, Apr 4, 2008 at 7:02 PM, Lennart Borgman (gmail)
>> <lennart.borgman@gmail.com> wrote:
>>  
>>>      But please notice that this is with my slightly patched version 
>>> (v 23,
>>> 2008-04-03).
>>>     
> 
> Can you both please try the latest version. I fixed a bug yesterday with 
> the text extents, which could explain the described behaviour.
> It does not seem to flicker for me now, though admittedly I have seen it 
> in the past.

I just did a quick test and I see no flickering now. That is very good, 
thanks.

However moving with up/down arrows is still very slow. If I hold down 
the up or down arrow the point cursor jumps. (When I use 
--disable-font-backend it moves more smoothly.)




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-04 12:54           ` Juanma Barranquero
  2008-04-04 17:02             ` Lennart Borgman (gmail)
@ 2008-04-06  1:14             ` Jason Rumney
  2008-04-06  1:47               ` Juanma Barranquero
  1 sibling, 1 reply; 23+ messages in thread
From: Jason Rumney @ 2008-04-06  1:14 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

Juanma Barranquero wrote:
> It is still slow, though. From  "emacs -Q -f view-hello-file" to
> actually see etc/HELLO, about 8-10 seconds, or three times slower than
> the same operation using --disable-font-backend.
>   

I see a 5 second vs 3 second delay, but it'll depend on how many and 
which fonts you have installed. I don't think a performance hit can be 
avoided, as font enumeration is slow on Windows anyway, and we are 
searching for fonts in far more detail than before, especially for 
complex South and South East Asian scripts. Once a font is found, it is 
cached, so the slowdown only occurs the first time you encounter a 
character that needs an as yet unknown font.






^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-06  1:14             ` Jason Rumney
@ 2008-04-06  1:47               ` Juanma Barranquero
  2008-04-06 13:42                 ` Jason Rumney
  0 siblings, 1 reply; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-06  1:47 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

On Sun, Apr 6, 2008 at 3:14 AM, Jason Rumney <jasonr@gnu.org> wrote:

> I don't think a performance hit can be avoided, as
> font enumeration is slow on Windows anyway, and we are searching for fonts
> in far more detail than before, especially for complex South and South East
> Asian scripts.

Fair enough.

But some operations are still too slow to be useful. Scrolling
etc/NEWS (with presumably contains not many non-ASCII chars) with the
new backend is unbearable, for example.

 Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-06  1:47               ` Juanma Barranquero
@ 2008-04-06 13:42                 ` Jason Rumney
  2008-04-06 15:36                   ` Óscar Fuentes
  2008-04-07 10:37                   ` Juanma Barranquero
  0 siblings, 2 replies; 23+ messages in thread
From: Jason Rumney @ 2008-04-06 13:42 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

Juanma Barranquero wrote:
> But some operations are still too slow to be useful. Scrolling
> etc/NEWS (with presumably contains not many non-ASCII chars) with the
> new backend is unbearable, for example.
>   

C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I 
think you'll need to debug why it is taking so long on your machine.




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-06 13:42                 ` Jason Rumney
@ 2008-04-06 15:36                   ` Óscar Fuentes
  2008-04-07 10:37                   ` Juanma Barranquero
  1 sibling, 0 replies; 23+ messages in thread
From: Óscar Fuentes @ 2008-04-06 15:36 UTC (permalink / raw)
  To: emacs-devel

Jason Rumney <jasonr@gnu.org> writes:

> Juanma Barranquero wrote:
>> But some operations are still too slow to be useful. Scrolling
>> etc/NEWS (with presumably contains not many non-ASCII chars) with the
>> new backend is unbearable, for example.
>>   
>
> C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I
> think you'll need to debug why it is taking so long on your machine.

What machine are you using? On a 550 MHz Athlon it is very slow: you can
see how the screen is repainted, the CPU usage goes to 100% and, if you
keep C-v pressed, no redraw is performed until the the end of the buffer
is reached. When I keep C-v pressed on the same Emacs started with
--disable-font-backend, CPU activity is below 15%.

On a 2 GHz Pentium M, Emacs uses more than 50% CPU load while scrolling
etc/NEWS.

-- 
Oscar





^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-06 13:42                 ` Jason Rumney
  2008-04-06 15:36                   ` Óscar Fuentes
@ 2008-04-07 10:37                   ` Juanma Barranquero
  2008-04-07 11:03                     ` Jason Rumney
  1 sibling, 1 reply; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-07 10:37 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

On Sun, Apr 6, 2008 at 3:42 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I think
> you'll need to debug why it is taking so long on your machine.

I'm not talking about C-v. I'm talking about scrolling one line at a time.

I use this in my .emacs

(setq scroll-preserve-screen-position 'always
      scroll-conservatively most-positive-fixnum
      scroll-step 0)

because I *hate* recentering during scroll.

If you try the above setup with and without the new backend, you'll
see the difference, I think.

   Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-07 10:37                   ` Juanma Barranquero
@ 2008-04-07 11:03                     ` Jason Rumney
  2008-04-07 11:22                       ` Juanma Barranquero
  0 siblings, 1 reply; 23+ messages in thread
From: Jason Rumney @ 2008-04-07 11:03 UTC (permalink / raw)
  To: Juanma Barranquero; +Cc: Emacs Devel

Juanma Barranquero wrote:
> On Sun, Apr 6, 2008 at 3:42 PM, Jason Rumney <jasonr@gnu.org> wrote:
>
>   
>>  C-v in a buffer viewing etc/NEWS is near instantaneous for me, so I think
>> you'll need to debug why it is taking so long on your machine.
>>     
>
> I'm not talking about C-v. I'm talking about scrolling one line at a time.
>
> I use this in my .emacs
>
> (setq scroll-preserve-screen-position 'always
>       scroll-conservatively most-positive-fixnum
>       scroll-step 0)
>
> because I *hate* recentering during scroll.
>
> If you try the above setup with and without the new backend, you'll
> see the difference, I think.
>   

I don't see a significant difference, certainly nothing to justify 
language like "unusable" and "unbearable" that has been used on this 
thread. Both recenter occasionally when the redisplay cannot keep up 
with key repeat, with the new font  backend it may happen more 
frequently, but that is not surprising for new development code that has 
not yet settled down, so noone has tried to optimize it yet.





^ permalink raw reply	[flat|nested] 23+ messages in thread

* Re: Assertion failes in w32uniscribe.c
  2008-04-07 11:03                     ` Jason Rumney
@ 2008-04-07 11:22                       ` Juanma Barranquero
  0 siblings, 0 replies; 23+ messages in thread
From: Juanma Barranquero @ 2008-04-07 11:22 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Emacs Devel

On Mon, Apr 7, 2008 at 1:03 PM, Jason Rumney <jasonr@gnu.org> wrote:

>  I don't see a significant difference

Well, THAT is surprising. They are not comparable at all for me. In my
setup, with the variable settings I reported, the old backend keeps up
with key repeat and I can scroll one line at a time as long as I want
(that's so in two different computers, with different XP versions,
different CPUs, etc.); and the redisplay during the scroll is smooth.
The new backend either scrolls visibly slow or, often, it just
recenters.

> certainly nothing to justify language like "unusable" and "unbearable" that has been used on this thread.

For my use and scrolling habits, the new backend is unusable and
unbearable. That's a fact: I wouldn't be able to use the CVS Emacs
right now, were not for --disable-font-backend. But that is not a
complain, I'm *reporting* one case of quite noticeable slowness in one
particular use case (scrolling one line at a time) that is perhaps
less usual that the "use C-v/M-v a lot and let next-line/previous-line
ocassionally recenter" behavior that many people prefers.

That said, if you take offense to my choice of words, I apologize and
will try to be more careful from now on. I wasn't trying to slight the
work you've done with the new backend, which is great.

 Juanma




^ permalink raw reply	[flat|nested] 23+ messages in thread

end of thread, other threads:[~2008-04-07 11:22 UTC | newest]

Thread overview: 23+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-04-03 14:41 Assertion failes in w32uniscribe.c Juanma Barranquero
2008-04-03 15:06 ` Jason Rumney
2008-04-03 17:22   ` Juanma Barranquero
2008-04-04  8:14     ` Jason Rumney
2008-04-04  9:17       ` Juanma Barranquero
2008-04-04  9:42         ` Jason Rumney
2008-04-04  9:35       ` Juanma Barranquero
2008-04-04 10:29         ` Jason Rumney
2008-04-04 11:40           ` Juanma Barranquero
2008-04-04 11:44             ` Juanma Barranquero
2008-04-04 12:54           ` Juanma Barranquero
2008-04-04 17:02             ` Lennart Borgman (gmail)
2008-04-04 17:50               ` Claus
2008-04-04 20:34                 ` Jason Rumney
2008-04-04 22:53                   ` Lennart Borgman (gmail)
2008-04-04 19:32               ` Óscar Fuentes
2008-04-06  1:14             ` Jason Rumney
2008-04-06  1:47               ` Juanma Barranquero
2008-04-06 13:42                 ` Jason Rumney
2008-04-06 15:36                   ` Óscar Fuentes
2008-04-07 10:37                   ` Juanma Barranquero
2008-04-07 11:03                     ` Jason Rumney
2008-04-07 11:22                       ` Juanma Barranquero

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.