On Thu, Aug 6, 2009 at 1:59 PM, Jean-Philippe
Bernardy wrote:
> I think it would be better to measure this with the fundamental mode.
> It makes sense to speed up syntax highlighting only once the basic
> functionality has decent performance.
That's fine; it's merely necessary to comment out the
On Thu, Aug 6, 2009 at 7:56 PM, Jeff Wheeler wrote:
>
> On Aug 6, 12:55 pm, Jeff Wheeler wrote:
>
>> Colin has written a far more clever config file [1] for Pango which Yi
>> renders along the way, and it gives a much more accurate time.
>
I think it would be better to measure this with the fund
On Aug 6, 12:55 pm, Jeff Wheeler wrote:
> Colin has written a far more clever config file [1] for Pango which Yi
> renders along the way, and it gives a much more accurate time.
Ack, that should have been: http://hpaste.org/fastcgi/hpaste.fcgi/view?id=7932
Sorry,
Jeff Wheeler
--~--~-~
Colin has written a far more clever config file [1] for Pango which Yi
renders along the way, and it gives a much more accurate time.
It takes a fairly consistent 24 seconds to run on my machine with the
current 500 character limit.
Jeff Wheeler
[1] http://hpaste.org/fastcgi/hpaste.fcgi/view?id
On Wed, Aug 5, 2009 at 12:17 PM, Colin McQuillan wrote:
> This sounds like what happened to me. Could you try the gtk2hs
> "finalizer-threads.dpatch" attached to
After applying that patch and merging the small conflict, I'm having
much more success with the Cmcq config. I've uploaded the current
2009/8/5 Jeff Wheeler :
>
> I've been trying to get objective measures of performance for Pango,
> but I get strange and inconsistent crahes when I attempt to use the
> Yi.Users.Cmcq config for Pango. I replaced the two lines (13/14) that
> handle the timing with simply: time dist/build/yi/yi time
I've been trying to get objective measures of performance for Pango,
but I get strange and inconsistent crahes when I attempt to use the
Yi.Users.Cmcq config for Pango. I replaced the two lines (13/14) that
handle the timing with simply: time dist/build/yi/yi time "$@", which
reveals the various e
On Thu, Jul 30, 2009 at 12:35 PM, Colin McQuillan wrote:
> One small optimization would be to use a separate pango layout object
> for each line and only update the lines that change.
I can only assume that applications using pango use only one pango object,
and therefore there is some possible
2009/7/30 Jean-Philippe Bernardy :
>
> On Thu, Jul 30, 2009 at 10:20 AM, Krasimir Angelov
> wrote:
>
>> I am surprised that you redraw the whole screen after each change.
>> This is not the conventional solution and this is the problem. The
>> solutions should be something like this:
>>
>> - the
2009/7/30 Jean-Philippe Bernardy :
...
>> IIRC, Yi.Vty.drawText (which basically takes a string and decides
>> where each character should go on a 80x24 console) typically takes
>> more than 50ms. So either it needs to be optimized by memoizing the
>> layout information, or cursor movements should
On Thu, Jul 30, 2009 at 11:46 AM, Colin McQuillan wrote:
> vty only provides a blocking getEvent. But at the tty level, it is
> possible to see if there is input pending using FIONREAD or just a
> non-blocking read. And in gtk there is a call to determine whether
> there are still unhanded events
2009/7/30 Jean-Philippe Bernardy :
>
> On Thu, Jul 30, 2009 at 10:13 AM, Colin McQuillan
> wrote:
>
>> What operation will asynchronous rendering make faster?
>
> There are two operations that are costly: (supposedly)
> 1. Computing the information to show the user (ui-independent)
> 2. Putting
On Thu, Jul 30, 2009 at 10:20 AM, Krasimir Angelov wrote:
> I am surprised that you redraw the whole screen after each change.
> This is not the conventional solution and this is the problem. The
> solutions should be something like this:
>
> - the UI independent code should calculate which area
On Thu, Jul 30, 2009 at 10:13 AM, Colin McQuillan wrote:
> What operation will asynchronous rendering make faster?
There are two operations that are costly: (supposedly)
1. Computing the information to show the user (ui-independent)
2. Putting that information on the screen (ui-dependent)
T
Hi,
As far as I remember the problem was that with the threads the UI was
too slow. It was basically working but from time to time it was just
freezing for few milliseconds and then continues. My guess was that
the thread switching takes some time and that this causes the problem.
Indeed when I r
2009/7/30 Jeff Wheeler :
>
> I've been reading back through issue #265 [1], and I expect that most
> of these comments apply to Pango. Particularly, drawing in a separate
> thread would be useful, I expect, and perhaps doing the syntax
> highlighting separately would be useful, too.
>
> I'm not at
On Thu, Jul 30, 2009 at 3:53 AM, Jeff Wheeler wrote:
>
> I've been reading back through issue #265 [1], and I expect that most
> of these comments apply to Pango.
Actually, pasting works great in Pango. (single operation!)
Now, the speed on both UI is appalling. I find #214 especially worrying,
On Thu, Jul 30, 2009 at 4:24 AM, Jason Foutz wrote:
>
> I'm not familiar enough with yi to know where to put the split, but
> yeah, approach sounds exactly right.
> Somewhere, you'll have some code that looks just about like this.
> [...]
Agreed, this might improve the situation. However, an impo
I'm not familiar enough with yi to know where to put the split, but
yeah, approach sounds exactly right.
Somewhere, you'll have some code that looks just about like this.
splitPango = do
done <- newEmptyMVar
chan <- newChan
forkIO $ drawPango done chan --or forkOS, hask
I've been reading back through issue #265 [1], and I expect that most
of these comments apply to Pango. Particularly, drawing in a separate
thread would be useful, I expect, and perhaps doing the syntax
highlighting separately would be useful, too.
I'm not at all experienced in threading in Haske
20 matches
Mail list logo
