On Tue, 4 Feb 2014, glpu...@gmail.com wrote:
Hi all,
I would like to do a “simple poll” to know your opinion.
I developed a lot of Delphi in the past, and I like it very much. Some weeks
ago I returned to Delphi from an
outsourcing, and worked under Delphi 6, and remembered how I loved Obje
On Tuesday, 04 February, 2014 04:38 PM, Michael Van Canneyt wrote:
>
>
> On Tue, 4 Feb 2014, Allan E. Registos wrote:
>
>> Hello to all,
>>
>> (Part of this mail also I posted earlier at the Lazarus forum).
>>
>> If anyone can refer a resource person who is more willing to a write
>> a review of F
Reimar Grabowski wrote:
On Tue, 04 Feb 2014 18:21:14 +
Mark Morgan Lloyd wrote:
With the major caveat that the interfaces used for playing video and for
program-generated graphics are distinct (hardware MPEG decompression in
one case, OpenGL in the other) and having one work implies nothi
On Tue, 04 Feb 2014 18:21:14 +
Mark Morgan Lloyd wrote:
> With the major caveat that the interfaces used for playing video and for
> program-generated graphics are distinct (hardware MPEG decompression in
> one case, OpenGL in the other) and having one work implies nothing about
> the othe
Michael Schnell schrieb:
On 02/04/2014 12:09 PM, Hans-Peter Diettrich wrote:
Right, and the restriction to one widgetset resides in the Lazarus
widgetset handling.
I do know. But it does not make much sense to be nagging towards the
powers here about LCL not being reentrant, if the library
Michael Van Canneyt wrote:
But this does not enable you to process the *information* displayed
at such a speed.
As stated in my last mail the USAF and their pilots do not share your
opinion.
Please... These people are primed for this kind of thing.
But the general discussion didn't say that
Reimar Grabowski wrote:
On Tue, 04 Feb 2014 14:19:07 +
Mark Morgan Lloyd wrote:
and in my experience the thing that's most likely to work is DVD
playback because the data stream is (as I understand it) sent via a
backdoor to the graphics chips bypassing most of the kernel and X.
On Linux
Michael Van Canneyt wrote:
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
In addition, there are standards for e.g. flashing indicators in
safety-critical applications which are specified with much finer
resolution than 100 mSec.
So a 10Hz update is totally out of the question these days: 100
Hi all,
I would like to do a “simple poll” to know your opinion.
I developed a lot of Delphi in the past, and I like it very much. Some weeks
ago I returned to Delphi from an outsourcing, and worked under Delphi 6, and
remembered how I loved Object Pascal.
I’m on a position where we have t
On Tue, 4 Feb 2014 17:07:23 +0100 (CET)
Michael Van Canneyt wrote:
> >> But this does not enable you to process the *information* displayed at
> >> such a speed.
> > As stated in my last mail the USAF and their pilots do not share your
> > opinion.
>
> Please... These people are primed for thi
On Tue, 4 Feb 2014, Reimar Grabowski wrote:
On Tue, 4 Feb 2014 15:59:07 +0100 (CET)
Michael Van Canneyt wrote:
Traditional Film uses 24 FPS, this was considered twice the speed of what was/is
needed to experience motion 'fluently'.
It is not unusual to show the same frame three times to br
On 04/02/14 15:15, Michael Van Canneyt wrote:
>
>
[...]
>
> I would be very interested to see experiments proving that this will
> make an actual difference in human operator efficiency.
>
I know this is completely different ballpark, but, why do you think,
3d games are all in pursuit of FPS ?
On Tue, 4 Feb 2014 15:59:07 +0100 (CET)
Michael Van Canneyt wrote:
> Traditional Film uses 24 FPS, this was considered twice the speed of what
> was/is
> needed to experience motion 'fluently'.
It is not unusual to show the same frame three times to bring the framerate up
to 72fps to reduce th
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
But complicated information like statistics or information of 20 cameras,
needs time to be processed by the brain in order to react on it. There is
therefor no need to have
On Tue, 4 Feb 2014, Reimar Grabowski wrote:
On Tue, 4 Feb 2014 14:40:21 +0100 (CET)
Michael Van Canneyt wrote:
The GUI is for use by humans. That means that there is no point whatsoever
in updating the GUI more than 10 times per second: the human eye cannot
process information faster than t
On Tue, 04 Feb 2014 14:19:07 +
Mark Morgan Lloyd wrote:
> and in my experience the thing that's most likely to work is DVD
> playback because the data stream is (as I understand it) sent via a
> backdoor to the graphics chips bypassing most of the kernel and X.
On Linux and BSD at least it'
Michael Van Canneyt wrote:
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
But complicated information like statistics or information of 20 cameras,
needs time to be processed by the brain in order to react on it. There
is therefor no need to have it refreshed in intervals that the brain
cannot
Am 04.02.2014 14:04, schrieb Michael Schnell:
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID
and every GUI widget is checked that it is owned by this thread ID as
well. Certain events like rendering are also checked for the thread ID
On Tue, 4 Feb 2014 14:40:21 +0100 (CET)
Michael Van Canneyt wrote:
> The GUI is for use by humans. That means that there is no point whatsoever
> in updating the GUI more than 10 times per second: the human eye cannot
> process information faster than that, let alone that the brain can grasp
>
On Tue, 4 Feb 2014, Mark Morgan Lloyd wrote:
Michael Van Canneyt wrote:
The GUI is for use by humans. That means that there is no point whatsoever
in updating the GUI more than 10 times per second: the human eye cannot
process information faster than that, let alone that the brain can grasp
If you need examples of what can be done here are some i've made:
1. http://badsector.minus.com/mMhg91zP9 (almost everything is made in
Lazarus - the maze editor specifically was made in a few hours, ignore
the iOS stuff at the bottom those weren't made in Lazarus :-P)
2. https://github.com/badsec
Michael Van Canneyt wrote:
The GUI is for use by humans. That means that there is no point
whatsoever in updating the GUI more than 10 times per second: the human
eye cannot process information faster than that, let alone that the
brain can grasp the *meaning* of what the eye has seen in such
On Tue, 4 Feb 2014, Michael Schnell wrote:
On 02/04/2014 02:40 PM, Michael Van Canneyt wrote:
I play a video at full HD, 1 thread handles the screen display. It works
just fine,
Playing two videos at the same time does make sense in some applications (we
"create" 20 small "videos" in our a
On 02/04/2014 02:40 PM, Michael Van Canneyt wrote:
I play a video at full HD, 1 thread handles the screen display. It
works just fine,
Playing two videos at the same time does make sense in some applications
(we "create" 20 small "videos" in our application to have the user see
what the syste
On Tue, 4 Feb 2014, Michael Schnell wrote:
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID and
every GUI widget is checked that it is owned by this thread ID as well.
Certain events like rendering are also checked for the thread ID
On 02/04/2014 01:39 PM, Sven Barth wrote:
Upon creation of the QApplication class it remembers the thread ID and
every GUI widget is checked that it is owned by this thread ID as
well. Certain events like rendering are also checked for the thread ID.
While I don't exactly see the point (as eac
Am 04.02.2014 11:04, schrieb Michael Schnell:
Of course it might be that QT (or KDE) impose additional restrictions
(though I still suppose that this can be handles somehow).
No, this can not be handled somehow (and it's not KDE, but Qt itself):
Upon creation of the QApplication class it remem
On 02/04/2014 11:57 AM, Hans-Peter Diettrich wrote:
I've just visited the German Wikipedia page for Pascal, and found it
in questionable state, too.
+1
-Michael
--
___
Lazarus mailing list
Lazarus@lists.lazarus.freepascal.org
http://lists.lazarus
On 02/04/2014 12:09 PM, Hans-Peter Diettrich wrote:
Right, and the restriction to one widgetset resides in the Lazarus
widgetset handling.
I do know. But it does not make much sense to be nagging towards the
powers here about LCL not being reentrant, if the library (Widget Set,
...) it bind
On 02/04/2014 11:36 AM, Mark Morgan Lloyd wrote:
At that point why not bite the bullet and exploit GPU parallelism?
Yep ! :-)
(And this hint is going out to whom ? ;-) )
KDE and Qt are minor issues, far more significant is arbitrary
restrictions that GTK imposes because they envisage some us
Michael Schnell schrieb:
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make
sense to create multiple X sessions (i.e. one per thread) in a single
program.
This may make sense with remote displays.
Allan E. Registos schrieb:
Hello to all,
(Part of this mail also I posted earlier at the Lazarus forum).
I was skimming the BSD Magazine: FreeBSD Programming Primer.
In page 7 the magazine mentioned about Pascal this way:
Quote:
BASIC and Pascal are great for learning how to code,
but
Michael Schnell wrote:
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make
sense to create multiple X sessions (i.e. one per thread) in a single
program.
At that point why not bite the bullet and e
BTW.:
What we did to take advantage of the multicore architecture in fact was
creating multiple applications, each of which handles such a GUI element
in a dedicated Window that is automatically placed at the appropriate
location "above" the main window. But of course the overhead for
managin
On 02/04/2014 11:12 AM, Michael Van Canneyt wrote:
It kind of defeats the purpose, as it suggests that only 1 thread at a
time can access the display.
Of course concentrating the GUI stuff to a single thread makes things a
lot easier to handle.
But I already did explain the purpose I (once) ha
On Tue, 4 Feb 2014, Michael Schnell wrote:
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make sense to
create multiple X sessions (i.e. one per thread) in a single program.
Thread aware does not
I stumbled over this:
http://tronche.com/gui/x/xlib/display/XInitThreads.html
So Xlib is thread aware and they seem to suggest that it dopes make
sense to create multiple X sessions (i.e. one per thread) in a single
program.
(And I learned that in fact XInitThreads() can be called in Lazarus
Hi,
On 04/02/14 00:20, Allan E. Registos wrote:
> Hello to all,
>
> (Part of this mail also I posted earlier at the Lazarus forum).
>
> I was skimming the BSD Magazine: FreeBSD Programming Primer. In page
> 7 the magazine mentioned about Pascal this way:
>
[...][sorry had to skim the context a
On Tue, 4 Feb 2014, Allan E. Registos wrote:
Hello to all,
(Part of this mail also I posted earlier at the Lazarus forum).
If anyone can refer a resource person who is more willing to a write a review
of Free Pascal in the BSD magazine, please drop a reply or contact me so that I
can forwa
39 matches
Mail list logo
