Abdelrazak Younes wrote:
>> i dont know whether multithreading app must run on a single core
>> (because data are in the same address space?) or its shortcomming
>> of the implementaion we use.
>
> Neither of the two. The kernel chooses which tasks go where. Maybe your
> system is misconfigured...
On 01/13/2011 12:44 PM, Pavel Sanda wrote:
Peter Kümmel wrote:
1) would be costly in terms of performance
But aren't we in the times of "bored cores"? Technically it is
but the load _is_ not distributed for one lyx instance, so its
equal to the situation when you have one core. even stranger a
Am Donnerstag, 13. Januar 2011 schrieb Jürgen Spitzmüller:
> > ${boost_regex_sources})
>
> Kornel, I think it would be better if you added your comments to the
> respective trac ticket.
>
> Jürgen
Done.
Kornel
signature.asc
Description: This is a digitally signed message part.
Stephan Witt wrote:
> Ah... the original version simply was:
>
> DialogView::checkStatus() { updateView(); }
>
> So alternatively we may override Dialog::checkStatus() for GuiThesaurus.
> Possible patch is attached.
this one looks better, since it doesn't affect dialog:: routines,
the more that
Peter Kümmel wrote:
> > 1) would be costly in terms of performance
>
> But aren't we in the times of "bored cores"? Technically it is
but the load _is_ not distributed for one lyx instance, so its
equal to the situation when you have one core. even stranger and
i have already written about it - e
Kornel Benko wrote:
> I see. It may be, because we set unconditionally "STATIC" in case of
> internal boost.
>
> I would change the explicit use of STATIC in calls to add_library() macro.
>
> Edit boost/libs/signals/CMakeLists.txt
> 1.)line 20:
> -->: add_library(boost_signals ${l
Am Donnerstag, 13. Januar 2011 schrieb LyX Ticket Tracker:
> #7024: Build error with external boost and "shared libs" option set (cmake)
> -+--
> Reporter: kraymer | Owner: lasgouttes
> Type: defect | Sta
Am 13.01.2011 um 09:40 schrieb Pavel Sanda:
> Stephan Witt wrote:
>> What I do not understand:
>> why depends the call of GuiDialog::updateView() on the result of canApply()?
>
> these two commits may reveal something
> r22049 (younes, 'Factorize general code out of GuiDialog...')
Ah... the or
On 01/13/2011 10:05 AM, Jean-Marc Lasgouttes wrote:
Le 13 janv. 2011 à 09:42, Stephan Witt a écrit :
Am 13.01.2011 um 09:33 schrieb Pavel Sanda:
Abdelrazak Younes wrote:
To be on the save side - if nothing else is changed - you have to draw
letter by letter all the times anyway.
The option can
Le 13 janv. 2011 à 09:42, Stephan Witt a écrit :
Am 13.01.2011 um 09:33 schrieb Pavel Sanda:
>
>> Abdelrazak Younes wrote:
To be on the save side - if nothing else is changed - you have to draw
letter by letter all the times anyway.
>>>
>>> The option can set to true by default.
>>
>>
Am 13.01.2011 um 09:33 schrieb Pavel Sanda:
> Abdelrazak Younes wrote:
>>> To be on the save side - if nothing else is changed - you have to draw
>>> letter by letter all the times anyway.
>>
>> The option can set to true by default.
>
> i also wonder what the 'few more cpu cycles' mean. we are
>>> See ticket http://www.lyx.org/trac/ticket/6920
> There are three solutions:
>
> 1) compute the metrics 8 times for a word of 8 letters
> 2) draw letter by letter all the times.
> 3) or rely on more on Qt widgets (i.e. use QTextEdit) instead on doing
> our thing.
>
> 1) would be costly in te
Stephan Witt wrote:
> What I do not understand:
> why depends the call of GuiDialog::updateView() on the result of canApply()?
these two commits may reveal something
r22049 (younes, 'Factorize general code out of GuiDialog...')
r29217 (vfr, 'Enable dialogs that can apply for read-only documents.'
Am 13.01.2011 um 09:28 schrieb Abdelrazak Younes:
> On 01/13/2011 09:23 AM, Stephan Witt wrote:
>> Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
>>
>>> On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
> The metrics cache computes the width of every single character -
>>
Abdelrazak Younes wrote:
>> To be on the save side - if nothing else is changed - you have to draw
>> letter by letter all the times anyway.
>
> The option can set to true by default.
i also wonder what the 'few more cpu cycles' mean. we are already quite slow
at rendering...
pavel
On 01/13/2011 09:23 AM, Stephan Witt wrote:
Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance). But the
drawing i
Am 13.01.2011 um 09:07 schrieb Abdelrazak Younes:
> On 01/13/2011 08:48 AM, Pavel Sanda wrote:
>> Stephan Witt wrote:
>>> The metrics cache computes the width of every single character -
>>> inclusive cacheing of it (to get better performance). But the
>>> drawing is done with complete text string
This is fixed some while ago already. It mean adding 2 commas and 2 spaces and
2 commas ;), and I reported it to Qt as a little inconvenience.
Apparently, the fix didn't fix it for MacOsX ? Or haven't anyone checked yet.
I'm glad I can resolve "the most annoying bug" within 9 minutes.
Unfort
Abdelrazak Younes wrote:
> 1) would be costly in terms of performance
> 2) would add be need a bit more cpu and would have the side effect that
> kerning would not be as good Qt's word drawing. This is what we do already
> for arabic and hebrew.
> 3) is a very big task and an entirely unknown ter
Stephan Witt wrote:
> Bug 7235 isn't a duplicate of 6920. It's completely different.
sorry i mixed up things! this is indeed different bug.
pavel
Am 13.01.2011 um 09:05 schrieb Vincent van Ravesteijn:
>
>> i know nothing about windows, sorry.
>
> How can you live like that ???
It's a really good live.
(If it's about Microsoft Windows :-))
Stephan
Am 13.01.2011 um 08:57 schrieb Vincent van Ravesteijn:
> Op 13-1-2011 8:48, Pavel Sanda schreef:
>> Stephan Witt wrote:
>>> The metrics cache computes the width of every single character -
>>> inclusive cacheing of it (to get better performance). But the
>>> drawing is done with complete text stri
On 01/13/2011 08:48 AM, Pavel Sanda wrote:
Stephan Witt wrote:
The metrics cache computes the width of every single character -
inclusive cacheing of it (to get better performance). But the
drawing is done with complete text strings and if a font supports
kerning e.g. it's absolutely correct to
23 matches
Mail list logo
