Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c++ > #13615 > unrolled thread

Leigh's GUI [OT]

Back to article view | Back to comp.lang.c++

Contents

  Leigh's GUI [OT] "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-27 22:23 +0000
    Re: Leigh's GUI [OT] Leigh Johnston <leigh@i42.co.uk> - 2012-01-27 22:29 +0000
      Re: Leigh's GUI [OT] "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-28 00:09 +0000
        Re: Leigh's GUI [OT] Leigh Johnston <leigh@i42.co.uk> - 2012-01-28 13:01 +0000
          Re: Leigh's GUI [OT] "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-28 15:26 +0000
            Re: Leigh's GUI [OT] Leigh Johnston <leigh@i42.co.uk> - 2012-01-28 16:27 +0000
              Re: Leigh's GUI [OT] "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-28 16:37 +0000
                Re: Leigh's GUI [OT] Leigh Johnston <leigh@i42.co.uk> - 2012-01-28 19:16 +0000
                Re: Leigh's GUI [OT] 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 12:52 -0800
                  Re: Leigh's GUI [OT] "Paul" <pchrist<nospam>or@yahoo.co.uk> - 2012-01-28 22:26 +0000
                Re: Leigh's GUI [OT] Thomas Boell <tboell@domain.invalid> - 2012-02-01 13:57 +0100
        Re: Leigh's GUI [OT] 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 13:35 -0800
          Re: Leigh's GUI [OT] Ian Collins <ian-news@hotmail.com> - 2012-01-29 11:29 +1300
            Re: Leigh's GUI [OT] 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-28 14:46 -0800
              Re: Leigh's GUI [OT] Ian Collins <ian-news@hotmail.com> - 2012-01-29 12:28 +1300
                Re: Leigh's GUI [OT] 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-29 05:07 -0800
              Re: Leigh's GUI [OT] hanukas <jukka@liimatta.org> - 2012-01-30 00:55 -0800
                Re: Leigh's GUI [OT] 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-30 10:46 -0800
                  Re: Leigh's GUI [OT] hanukas <jukka@liimatta.org> - 2012-01-30 14:54 -0800
                  Re: Leigh's GUI [OT] Ian Collins <ian-news@hotmail.com> - 2012-01-31 18:21 +1300
            Re: Leigh's GUI [OT] 88888 Dihedral <dihedral88888@googlemail.com> - 2012-01-29 16:13 -0800

Page 1 of 2  [1] 2  Next page →

#13615 — Leigh's GUI [OT]

Hello
Leigh are you sure there is a market/requirement amongst Android developers 
for your C++ graphics thingy,  re: http://neogfx.org

I was looking at developing for Android it seems all applications run in a 
JVM. Sure native code can be used but this would be through JNI so I don't 
see how your neogfx program would work on an android system.



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [next] | [standalone]

#13616

On 27/01/2012 22:23, Paul <pchrist wrote:
> Hello
> Leigh are you sure there is a market/requirement amongst Android developers
> for your C++ graphics thingy,  re: http://neogfx.org
>
> I was looking at developing for Android it seems all applications run in a
> JVM. Sure native code can be used but this would be through JNI so I don't
> see how your neogfx program would work on an android system.

That is off-topic, yes.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13618

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
> On 27/01/2012 22:23, Paul <pchrist wrote:
>> Hello
>> Leigh are you sure there is a market/requirement amongst Android 
>> developers
>> for your C++ graphics thingy,  re: http://neogfx.org
>>
>> I was looking at developing for Android it seems all applications run in 
>> a
>> JVM. Sure native code can be used but this would be through JNI so I 
>> don't
>> see how your neogfx program would work on an android system.
>
> That is off-topic, yes.
>

Well I thought it may make an interesting discussion since there isn't much 
else going on around here.

The android OS has become quite a big player in the booming smartphone 
sector. I think most C++ programmers would be interested in what the C++ 
languages' role is in this OS.
AFAICT there is not a not much support for C++ at application level , other 
than through JNI. It would be interesting to see how C++ is being used in 
lower level devopment with this OS.

Anyways regards the neogfx thing , I don't see why you have chosen to make 
this GUI library compatable with two incompatable OS's. If you were 
targetting windows(CE) and android , I could see a connection. Anyways there 
is already a Graphics library on both windows and android and that is OpenGL 
but on android OpenGL is exposed as a Java interface as opposed to windows 
where it's exposed as a C++ API. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#13623

On 28/01/2012 00:09, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
>> On 27/01/2012 22:23, Paul<pchrist wrote:
>>> Hello
>>> Leigh are you sure there is a market/requirement amongst Android
>>> developers
>>> for your C++ graphics thingy,  re: http://neogfx.org
>>>
>>> I was looking at developing for Android it seems all applications run in
>>> a
>>> JVM. Sure native code can be used but this would be through JNI so I
>>> don't
>>> see how your neogfx program would work on an android system.
>>
>> That is off-topic, yes.
>>
>
> Well I thought it may make an interesting discussion since there isn't much
> else going on around here.
>
> The android OS has become quite a big player in the booming smartphone
> sector. I think most C++ programmers would be interested in what the C++
> languages' role is in this OS.
> AFAICT there is not a not much support for C++ at application level , other
> than through JNI. It would be interesting to see how C++ is being used in
> lower level devopment with this OS.

You have obviously not done much research; see "Necessitas" (Qt for 
Android).

>
> Anyways regards the neogfx thing , I don't see why you have chosen to make
> this GUI library compatable with two incompatable OS's. If you were

The whole point of a cross-platfrom library is to support multiple 
incompatible operating systems.

> targetting windows(CE) and android , I could see a connection. Anyways there
> is already a Graphics library on both windows and android and that is OpenGL
> but on android OpenGL is exposed as a Java interface as opposed to windows
> where it's exposed as a C++ API.

A GUI library is not a graphics library.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13624

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:CqSdnWPV0446bL7SnZ2dnUVZ8kqdnZ2d@giganews.com...
> On 28/01/2012 00:09, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
>>> On 27/01/2012 22:23, Paul<pchrist wrote:
>>>> Hello
>>>> Leigh are you sure there is a market/requirement amongst Android
>>>> developers
>>>> for your C++ graphics thingy,  re: http://neogfx.org
>>>>
>>>> I was looking at developing for Android it seems all applications run 
>>>> in
>>>> a
>>>> JVM. Sure native code can be used but this would be through JNI so I
>>>> don't
>>>> see how your neogfx program would work on an android system.
>>>
>>> That is off-topic, yes.
>>>
>>
>> Well I thought it may make an interesting discussion since there isn't 
>> much
>> else going on around here.
>>
>> The android OS has become quite a big player in the booming smartphone
>> sector. I think most C++ programmers would be interested in what the C++
>> languages' role is in this OS.
>> AFAICT there is not a not much support for C++ at application level , 
>> other
>> than through JNI. It would be interesting to see how C++ is being used in
>> lower level devopment with this OS.
>
> You have obviously not done much research; see "Necessitas" (Qt for 
> Android).
>
Qt applications on android are Java applications that run in VM. They use 
JNI to access native code, see the NDK link at end of this post.

>>
>> Anyways regards the neogfx thing , I don't see why you have chosen to 
>> make
>> this GUI library compatable with two incompatable OS's. If you were
>
> The whole point of a cross-platfrom library is to support multiple 
> incompatible operating systems.
>
But a Graphical User Interface library that is suitable for small 
touchscreen phones would not have the same features as for a PC.


>> targetting windows(CE) and android , I could see a connection. Anyways 
>> there
>> is already a Graphics library on both windows and android and that is 
>> OpenGL
>> but on android OpenGL is exposed as a Java interface as opposed to 
>> windows
>> where it's exposed as a C++ API.
>
> A GUI library is not a graphics library.
>
Android already has a good GUI library and its very easy to implement using 
simple XML see:
http://developer.android.com/guide/topics/ui/index.html


The only support for C++( or C99) I can find is renderscript:
http://developer.android.com/guide/topics/renderscript/index.html

and via the NDK ref:
http://developer.android.com/sdk/ndk/overview.html



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#13626

On 28/01/2012 15:26, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:CqSdnWPV0446bL7SnZ2dnUVZ8kqdnZ2d@giganews.com...
>> On 28/01/2012 00:09, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
>>>> On 27/01/2012 22:23, Paul<pchrist wrote:
>>>>> Hello
>>>>> Leigh are you sure there is a market/requirement amongst Android
>>>>> developers
>>>>> for your C++ graphics thingy,  re: http://neogfx.org
>>>>>
>>>>> I was looking at developing for Android it seems all applications run
>>>>> in
>>>>> a
>>>>> JVM. Sure native code can be used but this would be through JNI so I
>>>>> don't
>>>>> see how your neogfx program would work on an android system.
>>>>
>>>> That is off-topic, yes.
>>>>
>>>
>>> Well I thought it may make an interesting discussion since there isn't
>>> much
>>> else going on around here.
>>>
>>> The android OS has become quite a big player in the booming smartphone
>>> sector. I think most C++ programmers would be interested in what the C++
>>> languages' role is in this OS.
>>> AFAICT there is not a not much support for C++ at application level ,
>>> other
>>> than through JNI. It would be interesting to see how C++ is being used in
>>> lower level devopment with this OS.
>>
>> You have obviously not done much research; see "Necessitas" (Qt for
>> Android).
>>
> Qt applications on android are Java applications that run in VM. They use
> JNI to access native code, see the NDK link at end of this post.

You obviously do not know what Qt is: Qt is a C++ GUI library not a Java 
GUI library.  How an Android Qt application runs and how it is split 
between native and JVM parts is an implementation detail of the library 
itself and that should not have any direct bearing on the C++ Qt 
application.

>
>>>
>>> Anyways regards the neogfx thing , I don't see why you have chosen to
>>> make
>>> this GUI library compatable with two incompatable OS's. If you were
>>
>> The whole point of a cross-platfrom library is to support multiple
>> incompatible operating systems.
>>
> But a Graphical User Interface library that is suitable for small
> touchscreen phones would not have the same features as for a PC.

Nonsense; a tablet is not that much different to a laptop with regards 
to screen size.  The majority of an application's implementation should 
be common to all platforms and other parts can be tailored to the target 
platform.  My library allows widget dimensions to be specified in inches 
rather than pixels for example to facilitate device agnostic design.

>>> targetting windows(CE) and android , I could see a connection. Anyways
>>> there
>>> is already a Graphics library on both windows and android and that is
>>> OpenGL
>>> but on android OpenGL is exposed as a Java interface as opposed to
>>> windows
>>> where it's exposed as a C++ API.
>>
>> A GUI library is not a graphics library.
>>
> Android already has a good GUI library and its very easy to implement using
> simple XML see:
> http://developer.android.com/guide/topics/ui/index.html

It should be obvious that I am not interested in Java Android App 
development.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13627

"Leigh Johnston" <leigh@i42.co.uk> wrote in message 
news:PtmdnaIGhqdBvLnSnZ2dnUVZ7s6dnZ2d@giganews.com...
> On 28/01/2012 15:26, Paul <pchrist wrote:
>> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
>> news:CqSdnWPV0446bL7SnZ2dnUVZ8kqdnZ2d@giganews.com...
>>> On 28/01/2012 00:09, Paul<pchrist wrote:
>>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>>> news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
>>>>> On 27/01/2012 22:23, Paul<pchrist wrote:
>>>>>> Hello
>>>>>> Leigh are you sure there is a market/requirement amongst Android
>>>>>> developers
>>>>>> for your C++ graphics thingy,  re: http://neogfx.org
>>>>>>
>>>>>> I was looking at developing for Android it seems all applications run
>>>>>> in
>>>>>> a
>>>>>> JVM. Sure native code can be used but this would be through JNI so I
>>>>>> don't
>>>>>> see how your neogfx program would work on an android system.
>>>>>
>>>>> That is off-topic, yes.
>>>>>
>>>>
>>>> Well I thought it may make an interesting discussion since there isn't
>>>> much
>>>> else going on around here.
>>>>
>>>> The android OS has become quite a big player in the booming smartphone
>>>> sector. I think most C++ programmers would be interested in what the 
>>>> C++
>>>> languages' role is in this OS.
>>>> AFAICT there is not a not much support for C++ at application level ,
>>>> other
>>>> than through JNI. It would be interesting to see how C++ is being used 
>>>> in
>>>> lower level devopment with this OS.
>>>
>>> You have obviously not done much research; see "Necessitas" (Qt for
>>> Android).
>>>
>> Qt applications on android are Java applications that run in VM. They use
>> JNI to access native code, see the NDK link at end of this post.
>
> You obviously do not know what Qt is: Qt is a C++ GUI library not a Java 
> GUI library.  How an Android Qt application runs and how it is split 
> between native and JVM parts is an implementation detail of the library 
> itself and that should not have any direct bearing on the C++ Qt 
> application.
>
>>
>>>>
>>>> Anyways regards the neogfx thing , I don't see why you have chosen to
>>>> make
>>>> this GUI library compatable with two incompatable OS's. If you were
>>>
>>> The whole point of a cross-platfrom library is to support multiple
>>> incompatible operating systems.
>>>
>> But a Graphical User Interface library that is suitable for small
>> touchscreen phones would not have the same features as for a PC.
>
> Nonsense; a tablet is not that much different to a laptop with regards to 
> screen size.  The majority of an application's implementation should be 
> common to all platforms and other parts can be tailored to the target 
> platform.  My library allows widget dimensions to be specified in inches 
> rather than pixels for example to facilitate device agnostic design.
>

A GUI designed for a touchscreen device will be alot different from a GUI 
designed for a PC with standard mouse/keyboard input. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#13628

On 28/01/2012 16:37, Paul <pchrist wrote:
> "Leigh Johnston"<leigh@i42.co.uk>  wrote in message
> news:PtmdnaIGhqdBvLnSnZ2dnUVZ7s6dnZ2d@giganews.com...
>> On 28/01/2012 15:26, Paul<pchrist wrote:
>>> "Leigh Johnston"<leigh@i42.co.uk>   wrote in message
>>> news:CqSdnWPV0446bL7SnZ2dnUVZ8kqdnZ2d@giganews.com...
>>>> On 28/01/2012 00:09, Paul<pchrist wrote:

[snip]

>>>>> Anyways regards the neogfx thing , I don't see why you have chosen to
>>>>> make
>>>>> this GUI library compatable with two incompatable OS's. If you were
>>>>
>>>> The whole point of a cross-platfrom library is to support multiple
>>>> incompatible operating systems.
>>>>
>>> But a Graphical User Interface library that is suitable for small
>>> touchscreen phones would not have the same features as for a PC.
>>
>> Nonsense; a tablet is not that much different to a laptop with regards to
>> screen size.  The majority of an application's implementation should be
>> common to all platforms and other parts can be tailored to the target
>> platform.  My library allows widget dimensions to be specified in inches
>> rather than pixels for example to facilitate device agnostic design.
>>
>
> A GUI designed for a touchscreen device will be alot different from a GUI
> designed for a PC with standard mouse/keyboard input.

Untrue; a GUI designed for a touchscreen device can be quite similar to 
a GUI designed for a PC and in fact Windows 8 allows for both 
touchscreen and a keyboard/mouse.  There is no reason why an individual 
widget cannot work on both touchscreen devices and keyboard/mouse 
devices; what is more likely to differ is not widget code but layout code.

/Leigh

[toc] | [prev] | [next] | [standalone]

#13630

在 2012年1月29日星期日UTC+8上午12时37分36秒，Paul写道：
> "Leigh Johnston" <le...@i42.co.uk> wrote in message 
> news:PtmdnaIGhqdBvLnSnZ2dnUVZ7s6dnZ2d@giganews.com...
> > On 28/01/2012 15:26, Paul 
> > "Leigh Johnston"<le...@i42.co.uk>  wrote in message
> >> news:CqSdnWPV0446bL7SnZ2dnUVZ8kqdnZ2d@giganews.com...
> >>> On 28/01/2012 00:09, Paul
> >>> "Leigh Johnston"<le...@i42.co.uk>   wrote in message
> >>>> news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
> >>>>> On 27/01/2012 22:23, Paul
> >>>>> Hello
> >>>>>> Leigh are you sure there is a market/requirement amongst Android
> >>>>>> developers
> >>>>>> for your C++ graphics thingy,  re: http://neogfx.org
> >>>>>>
> >>>>>> I was looking at developing for Android it seems all applications run
> >>>>>> in
> >>>>>> a
> >>>>>> JVM. Sure native code can be used but this would be through JNI so I
> >>>>>> don't
> >>>>>> see how your neogfx program would work on an android system.
> >>>>>
> >>>>> That is off-topic, yes.
> >>>>>
> >>>>
> >>>> Well I thought it may make an interesting discussion since there isn't
> >>>> much
> >>>> else going on around here.
> >>>>
> >>>> The android OS has become quite a big player in the booming smartphone
> >>>> sector. I think most C++ programmers would be interested in what the 
> >>>> C++
> >>>> languages' role is in this OS.
> >>>> AFAICT there is not a not much support for C++ at application level ,
> >>>> other
> >>>> than through JNI. It would be interesting to see how C++ is being used 
> >>>> in
> >>>> lower level devopment with this OS.
> >>>
> >>> You have obviously not done much research; see "Necessitas" (Qt for
> >>> Android).
> >>>
> >> Qt applications on android are Java applications that run in VM. They use
> >> JNI to access native code, see the NDK link at end of this post.
> >
> > You obviously do not know what Qt is: Qt is a C++ GUI library not a Java 
> > GUI library.  How an Android Qt application runs and how it is split 
> > between native and JVM parts is an implementation detail of the library 
> > itself and that should not have any direct bearing on the C++ Qt 
> > application.
> >
> >>
> >>>>
> >>>> Anyways regards the neogfx thing , I don't see why you have chosen to
> >>>> make
> >>>> this GUI library compatable with two incompatable OS's. If you were
> >>>
> >>> The whole point of a cross-platfrom library is to support multiple
> >>> incompatible operating systems.
> >>>
> >> But a Graphical User Interface library that is suitable for small
> >> touchscreen phones would not have the same features as for a PC.
> >
> > Nonsense; a tablet is not that much different to a laptop with regards to 
> > screen size.  The majority of an application's implementation should be 
> > common to all platforms and other parts can be tailored to the target 
> > platform.  My library allows widget dimensions to be specified in inches 
> > rather than pixels for example to facilitate device agnostic design.
> >
> 
> A GUI designed for a touchscreen device will be alot different from a GUI 
> designed for a PC with standard mouse/keyboard input. 
> 
> 
> 
> --- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

The touch screen part is just another event generator hooked to the OS at all.
I don't agree that the a well designed GUI  library or package would be
limited by the OS.  The user interface part is not time critical in most 
message handling and dispatching jobs  to call  the part that really does the heavy computing works.  

[toc] | [prev] | [next] | [standalone]

#13634

"88888 Dihedral" <dihedral88888@googlemail.com> wrote in message 
news:5242308.346.1327783959182.JavaMail.geo-discussion-forums@prez15...
? 2012?1?29????UTC+8??12?37?36?,Paul??:
> "Leigh Johnston" <le...@i42.co.uk> wrote in message
> news:PtmdnaIGhqdBvLnSnZ2dnUVZ7s6dnZ2d@giganews.com...
> > On 28/01/2012 15:26, Paul
> > "Leigh Johnston"<le...@i42.co.uk>  wrote in message
> >> news:CqSdnWPV0446bL7SnZ2dnUVZ8kqdnZ2d@giganews.com...
> >>> On 28/01/2012 00:09, Paul
> >>> "Leigh Johnston"<le...@i42.co.uk>   wrote in message
> >>>> news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
> >>>>> On 27/01/2012 22:23, Paul
> >>>>> Hello
> >>>>>> Leigh are you sure there is a market/requirement amongst Android
> >>>>>> developers
> >>>>>> for your C++ graphics thingy,  re: http://neogfx.org
> >>>>>>
> >>>>>> I was looking at developing for Android it seems all applications 
> >>>>>> run
> >>>>>> in
> >>>>>> a
> >>>>>> JVM. Sure native code can be used but this would be through JNI so 
> >>>>>> I
> >>>>>> don't
> >>>>>> see how your neogfx program would work on an android system.
> >>>>>
> >>>>> That is off-topic, yes.
> >>>>>
> >>>>
> >>>> Well I thought it may make an interesting discussion since there 
> >>>> isn't
> >>>> much
> >>>> else going on around here.
> >>>>
> >>>> The android OS has become quite a big player in the booming 
> >>>> smartphone
> >>>> sector. I think most C++ programmers would be interested in what the
> >>>> C++
> >>>> languages' role is in this OS.
> >>>> AFAICT there is not a not much support for C++ at application level ,
> >>>> other
> >>>> than through JNI. It would be interesting to see how C++ is being 
> >>>> used
> >>>> in
> >>>> lower level devopment with this OS.
> >>>
> >>> You have obviously not done much research; see "Necessitas" (Qt for
> >>> Android).
> >>>
> >> Qt applications on android are Java applications that run in VM. They 
> >> use
> >> JNI to access native code, see the NDK link at end of this post.
> >
> > You obviously do not know what Qt is: Qt is a C++ GUI library not a Java
> > GUI library.  How an Android Qt application runs and how it is split
> > between native and JVM parts is an implementation detail of the library
> > itself and that should not have any direct bearing on the C++ Qt
> > application.
> >
> >>
> >>>>
> >>>> Anyways regards the neogfx thing , I don't see why you have chosen to
> >>>> make
> >>>> this GUI library compatable with two incompatable OS's. If you were
> >>>
> >>> The whole point of a cross-platfrom library is to support multiple
> >>> incompatible operating systems.
> >>>
> >> But a Graphical User Interface library that is suitable for small
> >> touchscreen phones would not have the same features as for a PC.
> >
> > Nonsense; a tablet is not that much different to a laptop with regards 
> > to
> > screen size.  The majority of an application's implementation should be
> > common to all platforms and other parts can be tailored to the target
> > platform.  My library allows widget dimensions to be specified in inches
> > rather than pixels for example to facilitate device agnostic design.
> >
>
> A GUI designed for a touchscreen device will be alot different from a GUI
> designed for a PC with standard mouse/keyboard input.
>
>
>
> --- Posted via news://freenews.netfront.net/ - Complaints to 
> ne...@netfront.net ---

--The touch screen part is just another event generator hooked to the OS at 
all.
--I don't agree that the a well designed GUI  library or package would be
--limited by the OS.  The user interface part is not time critical in most
--message handling and dispatching jobs  to call  the part that really does 
the heavy computing works.


GUI design is a branch of computer design/engineering in itself and I'm sure 
if you were to consult a GUI design expert you would be advised that 
smartphones and PC's are not comptable when it comes to GUI design.
This is the reason I query leigh's target market/users. I feel that android 
developers and  windows PC developers do not share a common GUI design 
objective. The GUI for a windows PC software program is never (or very 
rarely) going to be the same as that of a smartphone or android device. 



--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#13688

On Sat, 28 Jan 2012 16:37:36 -0000
"Paul" <pchrist<nospam>or@yahoo.co.uk> wrote:

> A GUI designed for a touchscreen device will be alot different from a GUI 
> designed for a PC with standard mouse/keyboard input. 

http://hyperboleandahalf.blogspot.com/2010/04/alot-is-better-than-you-at-everything.html

[toc] | [prev] | [next] | [standalone]

#13632

在 2012年1月28日星期六UTC+8上午8时09分22秒，Paul写道：
> "Leigh Johnston" <le...@i42.co.uk> wrote in message 
> news:WPOdnaY3rJP0uL7SnZ2dnUVZ8rOdnZ2d@giganews.com...
> > On 27/01/2012 22:23, Paul 
> > Hello
> >> Leigh are you sure there is a market/requirement amongst Android 
> >> developers
> >> for your C++ graphics thingy,  re: http://neogfx.org
> >>
> >> I was looking at developing for Android it seems all applications run in 
> >> a
> >> JVM. Sure native code can be used but this would be through JNI so I 
> >> don't
> >> see how your neogfx program would work on an android system.
> >
> > That is off-topic, yes.
> >
> 
> Well I thought it may make an interesting discussion since there isn't much 
> else going on around here.
> 
> The android OS has become quite a big player in the booming smartphone 
> sector. I think most C++ programmers would be interested in what the C++ 
> languages' role is in this OS.
> AFAICT there is not a not much support for C++ at application level , other 
> than through JNI. It would be interesting to see how C++ is being used in 
> lower level devopment with this OS.
> 
> Anyways regards the neogfx thing , I don't see why you have chosen to make 
> this GUI library compatable with two incompatable OS's. If you were 
> targetting windows(CE) and android , I could see a connection. Anyways there 
> is already a Graphics library on both windows and android and that is OpenGL 
> but on android OpenGL is exposed as a Java interface as opposed to windows 
> where it's exposed as a C++ API. 
> 
> 
> 
> --- Posted via news://freenews.netfront.net/ - Complaints to ne...@netfront.net ---

Don't be fool by Apple's consumer ready to use techie toys at all. 
The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
In this part C++ is not very useful for those DSP routines in mobile systems. 

 

[toc] | [prev] | [next] | [standalone]

#13635

On 01/29/12 10:35 AM, 88888 Dihedral wrote:

> The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
> In this part C++ is not very useful for those DSP routines in mobile systems.

The last mobile DSP project I was involved in used C++.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13640

在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
> On 01/29/12 10:35 AM, 88888 Dihedral wrote:
> 
> > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
> > In this part C++ is not very useful for those DSP routines in mobile systems.
> 
> The last mobile DSP project I was involved in used C++.
> 
> -- 
> Ian Collins

I'll use  pointers to  structures for any heavy computing jobs in DSP
in the C way. 

Even the v-pointer to the v-table for each element in 2D or 3D are
slowingdown the process.

Of course a lot people don't do digtal image or video processing for 
a window convolution larger than 16X16.

Just implement a Wiener filter of a simple model for an image of a high priced 
digital camcorder for hand shakinking elimanation of motion blurred sources,
then the C++ funny way is not very useful at all. 

 

[toc] | [prev] | [next] | [standalone]

#13642

On 01/29/12 11:46 AM, 88888 Dihedral wrote:
> 在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
>> On 01/29/12 10:35 AM, 88888 Dihedral wrote:
>>
>>> The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
>>> In this part C++ is not very useful for those DSP routines in mobile systems.
>>
>> The last mobile DSP project I was involved in used C++.

Please don't quote signatures

> I'll use  pointers to  structures for any heavy computing jobs in DSP
> in the C way.
>
> Even the v-pointer to the v-table for each element in 2D or 3D are
> slowingdown the process.
>
> Of course a lot people don't do digtal image or video processing for
> a window convolution larger than 16X16.

Even more people don't do any video processing.  DSPs have many uses.

> Just implement a Wiener filter of a simple model for an image of a high priced
> digital camcorder for hand shakinking elimanation of motion blurred sources,
> then the C++ funny way is not very useful at all.

What "C++ funny way"?  There are as many ways to use C++ as there are 
problems to solve.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#13648

在 2012年1月29日星期日UTC+8上午7时28分39秒，Ian Collins写道：
> On 01/29/12 11:46 AM, 88888 Dihedral wrote:
> > 在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
> >> On 01/29/12 10:35 AM, 88888 Dihedral wrote:
> >>
> >>> The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
> >>> In this part C++ is not very useful for those DSP routines in mobile systems.
> >>
> >> The last mobile DSP project I was involved in used C++.
> 
> Please don't quote signatures
> 
> > I'll use  pointers to  structures for any heavy computing jobs in DSP
> > in the C way.
> >
> > Even the v-pointer to the v-table for each element in 2D or 3D are
> > slowingdown the process.
> >
> > Of course a lot people don't do digtal image or video processing for
> > a window convolution larger than 16X16.
> 
> Even more people don't do any video processing.  DSPs have many uses.
> 
> > Just implement a Wiener filter of a simple model for an image of a high priced
> > digital camcorder for hand shakinking elimanation of motion blurred sources,
> > then the C++ funny way is not very useful at all.
> 
> What "C++ funny way"?  There are as many ways to use C++ as there are 
> problems to solve.
> 
> -- 
> Ian Collins

I'll make my point clear in heavy computing tasks. It is better to program
in registers directly supported in hardware operations without any extra-
overhead in the basic operations. 

Higher level languages that will introduce any overhead in basic operations are not very helpful in this situation.   

[toc] | [prev] | [next] | [standalone]

#13660

On Jan 29, 12:46 am, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> 在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
>
> > On 01/29/12 10:35 AM, 88888 Dihedral wrote:
>
> > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
> > > In this part C++ is not very useful for those DSP routines in mobile systems.
>
> > The last mobile DSP project I was involved in used C++.
>
> > --
> > Ian Collins
>
> I'll use  pointers to  structures for any heavy computing jobs in DSP
> in the C way.
>
> Even the v-pointer to the v-table for each element in 2D or 3D are
> slowingdown the process.

Of course. Same can be said about redundant computation, for example:

process_sample(x, y, ..);
-->
*(address + offset)
++offset
-->
~= address[offset++]

- avoid unnecessary method/function calls

- don't compute stride*y for each sample, you KNOW the address of next
sample when process samples in predictable order

- if you process samples in predictable order, you can also predict
the access pattern from cache's point of view; for 2D data, tile it
for better local coherency and minimize cache misses

- can you reduce ALU cost with data-level parallelism?

- can you reduce overhead with process level parallelism?

.. and other interesting architectural decisions that you can make. C/C
++ is irrelevant argument when the programmer is proficient. The C++
constructs allow more readable code with no performance impact. No one
is suggesting you need to invoke virtual c++ method call for each
processed sample, except you.. why are you using that as argument
against C++ if you are a very good programmer?


> Of course a lot people don't do digtal image or video processing for
> a window convolution larger than 16X16.

I do something where we have to process over 100,000,000 samples per
second, 1-2 million samples at 60 fps. It's called real-time
rendering. And we have to do that with only few watts, there isn't
much room to waste power on redundant computation.


> Just implement a Wiener filter of a simple model for an image of a high priced
> digital camcorder for hand shakinking elimanation of motion blurred sources,
> then the C++ funny way is not very useful at all.

The C++ funny way, whatever it is that you mean by that probably
isn't. But there is nothing in C (!) that it could do better. It comes
down to knowing what you are doing, sounds to me that you only know
how to write poorly performing C++ code so I would say that you're not
the best possible go-to guy for advice. No offence, it just comes out
that way.

[toc] | [prev] | [next] | [standalone]

#13667

在 2012年1月30日星期一UTC+8下午4时55分39秒，hanukas写道：
> On Jan 29, 12:46 am, 88888 Dihedral <dihedr...@googlemail.com>
> wrote:
> > 在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
> >
> > > On 01/29/12 10:35 AM, 88888 Dihedral wrote:
> >
> > > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
> > > > In this part C++ is not very useful for those DSP routines in mobile systems.
> >
> > > The last mobile DSP project I was involved in used C++.
> >
> > > --
> > > Ian Collins
> >
> > I'll use  pointers to  structures for any heavy computing jobs in DSP
> > in the C way.
> >
> > Even the v-pointer to the v-table for each element in 2D or 3D are
> > slowingdown the process.
> 
> Of course. Same can be said about redundant computation, for example:
> 
> process_sample(x, y, ..);
> -->
> *(address + offset)
> ++offset
> -->
> ~= address[offset++]
> 
> - avoid unnecessary method/function calls
> 
> - don't compute stride*y for each sample, you KNOW the address of next
> sample when process samples in predictable order
> 
> - if you process samples in predictable order, you can also predict
> the access pattern from cache's point of view; for 2D data, tile it
> for better local coherency and minimize cache misses
> 
> - can you reduce ALU cost with data-level parallelism?
> 
> - can you reduce overhead with process level parallelism?
> 
> .. and other interesting architectural decisions that you can make. C/C
> ++ is irrelevant argument when the programmer is proficient. The C++
> constructs allow more readable code with no performance impact. No one
> is suggesting you need to invoke virtual c++ method call for each
> processed sample, except you.. why are you using that as argument
> against C++ if you are a very good programmer?
> 
> 
> > Of course a lot people don't do digtal image or video processing for
> > a window convolution larger than 16X16.
> 
> I do something where we have to process over 100,000,000 samples per
> second, 1-2 million samples at 60 fps. It's called real-time
> rendering. And we have to do that with only few watts, there isn't
> much room to waste power on redundant computation.
> 
> 
> > Just implement a Wiener filter of a simple model for an image of a high priced
> > digital camcorder for hand shakinking elimanation of motion blurred sources,
> > then the C++ funny way is not very useful at all.
> 
> The C++ funny way, whatever it is that you mean by that probably
> isn't. But there is nothing in C (!) that it could do better. It comes
> down to knowing what you are doing, sounds to me that you only know
> how to write poorly performing C++ code so I would say that you're not
> the best possible go-to guy for advice. No offence, it just comes out
> that way.

What I have emphasized is that C++ is better in a high level of controls
of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be 
used for heavy computing in the low level that needs to deal with hardware
to avoid unnecessary overheads in repeated basic operations.  

[toc] | [prev] | [next] | [standalone]

#13671

On Jan 30, 8:46 pm, 88888 Dihedral <dihedral88...@googlemail.com>
wrote:
> 在 2012年1月30日星期一UTC+8下午4时55分39秒，hanukas写道：
>
>
>
>
>
>
>
>
>
> > On Jan 29, 12:46 am, 88888 Dihedral <dihedr...@googlemail.com>
> > wrote:
> > > 在 2012年1月29日星期日UTC+8上午6时29分10秒，Ian Collins写道：
>
> > > > On 01/29/12 10:35 AM, 88888 Dihedral wrote:
>
> > > > > The roadmap is WIMAX to LTE before 2020 to relpace the cheap old  GSM.
> > > > > In this part C++ is not very useful for those DSP routines in mobile systems.
>
> > > > The last mobile DSP project I was involved in used C++.
>
> > > > --
> > > > Ian Collins
>
> > > I'll use  pointers to  structures for any heavy computing jobs in DSP
> > > in the C way.
>
> > > Even the v-pointer to the v-table for each element in 2D or 3D are
> > > slowingdown the process.
>
> > Of course. Same can be said about redundant computation, for example:
>
> > process_sample(x, y, ..);
> > -->
> > *(address + offset)
> > ++offset
> > -->
> > ~= address[offset++]
>
> > - avoid unnecessary method/function calls
>
> > - don't compute stride*y for each sample, you KNOW the address of next
> > sample when process samples in predictable order
>
> > - if you process samples in predictable order, you can also predict
> > the access pattern from cache's point of view; for 2D data, tile it
> > for better local coherency and minimize cache misses
>
> > - can you reduce ALU cost with data-level parallelism?
>
> > - can you reduce overhead with process level parallelism?
>
> > .. and other interesting architectural decisions that you can make. C/C
> > ++ is irrelevant argument when the programmer is proficient. The C++
> > constructs allow more readable code with no performance impact. No one
> > is suggesting you need to invoke virtual c++ method call for each
> > processed sample, except you.. why are you using that as argument
> > against C++ if you are a very good programmer?
>
> > > Of course a lot people don't do digtal image or video processing for
> > > a window convolution larger than 16X16.
>
> > I do something where we have to process over 100,000,000 samples per
> > second, 1-2 million samples at 60 fps. It's called real-time
> > rendering. And we have to do that with only few watts, there isn't
> > much room to waste power on redundant computation.
>
> > > Just implement a Wiener filter of a simple model for an image of a high priced
> > > digital camcorder for hand shakinking elimanation of motion blurred sources,
> > > then the C++ funny way is not very useful at all.
>
> > The C++ funny way, whatever it is that you mean by that probably
> > isn't. But there is nothing in C (!) that it could do better. It comes
> > down to knowing what you are doing, sounds to me that you only know
> > how to write poorly performing C++ code so I would say that you're not
> > the best possible go-to guy for advice. No offence, it just comes out
> > that way.
>
> What I have emphasized is that C++ is better in a high level of controls
> of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be
> used for heavy computing in the low level that needs to deal with hardware
> to avoid unnecessary overheads in repeated basic operations.

For dealing with hardware there are two primary choices which are
preferred:

1. GPU: CUDA, OpenCL, OpenGL/GLSL, D3D/HLSL, Cg, etc.
2. CPU: SIMD/MT -JIT

The (1) is self-explatonary. The less often taken path is the (2),
which is very expensive to implement as in worst case it is task
comparable to writing optimizing compiler. In less complicated
scenario it is just putting macro blocks of machine code together in
controlled fashion. The middle ground is to generate the machine code
in intermediate format where all symbols are named and register
allocator is the largest single task to overcome.

In both cases the implementation language is not as interesting as
what is done with it. The (1) has the goal to create solid quality
microcode for the GPU to execute and have good paths for data to go
through. The (2) has the same idea, but instead of microcode we
generate code for the CPU ALU instead, the data paths are less
sensitive to latency but more sensitive to cache as this path is more
flexible than the streaming model preferred for GPU.

If you are writing inner loops in HLL like C/C++ in that case again,
the C does not offer any real-world advantage over C if the programmer
understands his tools and knows how the HLL constructs map into
hardware instructions. This requires some experience with the compiler
and linker toolchain to have realistic expectations of the outcome of
HLL expressions. Usually at this level two things are done:

1. The results are measured against other alternatives
2. The output assembly (.s, .asm) is inspected so that there aren't
any surprises like calls to _ftol, or call to inline method and so on.
Inline keyword cannot be trusted in generic portable code to always
get the job done, sure, macros and other constructs can be used to
guide the code into the right direction.

The main thing is to measure, profile and check the output and adjust
the source code accordingly. It is a realistic expectation that the
compilers get better over time, not worse, so any optimization along
these guidelines will stay effective. On the other hand, some work-
arounds to get better output become obsolete over time and more
straightforward and descriptive expression usually slowly gains
ground.

All code written with this mindset is CONTEMPORARY and gets STALE over
time! VERY important to keep in mind.

This kind of micro-optimization is unnecessary for most programmers
for most of the time. Especially now that we have hardware to process
streamed data. For example, seems that what you are working on is a 2D
matrix of input that you map into output with 2D, finite-size kernel..
this kind of workload is often ideal for graphics processor to take a
peek at. The problem with this kind of thinking is the round-trip to
GPU local address space and back, if you can't synchronize the data
processing w/o flushing you're better off using the CPU most of the
time, where the technique (2) comes in.

What I'm getting at in roundabout way is that the C vs. C++ argument
is out-dated and even if that is the language of choice for the actual
inner loop, the C++ doesn't have ANY disadvantage except poor
programmers. The C is more hard-core and has less facilities to fuck
things up if you don't know how everything works. IN THAT SENSE it is
much better choice rather than let some sloppy C++ programmer try to
do a good job w/ tool he has no idea how to use properly. The key
concept is that this same sloppy C++ programmer might be TOP GUN C
programmer, so let him use the tools he knows best. But this is
totally different argument than that the C++ is inherently slow; it's
not.

[toc] | [prev] | [next] | [standalone]

#13672

On 01/31/12 07:46 AM, 88888 Dihedral wrote:
>
> What I have emphasized is that C++ is better in a high level of controls
> of complex components organized as easy to use objects in a library or a package to be used by others, but it should not be
> used for heavy computing in the low level that needs to deal with hardware
> to avoid unnecessary overheads in repeated basic operations.

That problem only occurs if you don't know what you are doing.  The C++ 
overheads are no greater than C overheads for the same operations.

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c++

csiph-web