Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualCaburé

Posted 08 November 2012 - 10:31 AM

I am not saying java is bad or worse. It is different. I'll try to explain what I've got trying to use both OOP and needed software graphics simple operations as arraycopy and simple mean, additions/subtractions for bright/contrast (without hardware acceleration).


In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 = 120 ms) USING System.ArrayCopy (supposed to be the fastest way) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.


If you need precision, you must rely on hardware. Relying on hardware makes that assumption about "compile once, run anywhere" worse: C/C++ can be used to run software that binds straight to the OS, without balances and fixed panorama about a basic architeture and reasonable speed conform that design. Reasonable speed conform the design is something that must be very good in Java Code for you to have a good result if you pretend to port applications.

#11Caburé

Posted 08 November 2012 - 10:30 AM

I am not saying java is bad or worse. It is different. I'll try to explain what I've got trying to use both OOP and needed software graphics simple operations as arraycopy and simple mean, additions/subtractions for bright/contrast.


In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 = 120 ms) USING System.ArrayCopy (supposed to be the fastest way) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.


If you need precision, you must rely on hardware. Relying on hardware makes that assumption about "compile once, run anywhere" worse: C/C++ can be used to run software that binds straight to the OS, without balances and fixed panorama about a basic architeture and reasonable speed conform that design. Reasonable speed conform the design is something that must be very good in Java Code for you to have a good result if you pretend to port applications.

#10Caburé

Posted 08 November 2012 - 10:07 AM

In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 = 120 ms) USING System.ArrayCopy (supposed to be the fastest way) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.

#9Caburé

Posted 08 November 2012 - 10:07 AM

In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 = 120 ms) USING System.ArrayCopy (supposed to be the fastest way) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.

#8Caburé

Posted 08 November 2012 - 10:05 AM

In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 ms) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.

#7Caburé

Posted 08 November 2012 - 10:05 AM

In Java, you can't control things at the hardware level (you can just prepare data to send to it): you just write and hope it to run at reasonable speed and Java doesn't have accurate timers - even a diference of time can't be assured to be real. Example:

// compares two moments, in miliseconds

long time1 = System.currentTimeMilis();

anObject.doThings();

long timeElapsedMs = System.currentTimeMilis() - time1;

System.out.println(timeElapsedMs);

//--------------

The time shown above can't be trusted to be exact about the time ran.

I was once trying to use math to make a sequence of events to become stable by skipping fixed periods of time based on a known variation and sleeps, shifting from slow to fast to make all run in the expected framerate and I could not make it work because the time difference always were over a limit of ˜8FPS (1000/8 ms) - the job was to copy to a buffered image pixels the pixels of a source buffer, in the same format: Java schedules memory reallocation and garbage collection while in the loop and, for being so oriented to objects, I could never know when Java was bouncing the top amount of memory needed to keep the animation/reallocation (I tried to cut all to a fixed size copy/paste of memory) but for every single aspect, even to get current timedate you need a new object - new Date( ), for example. In the withins, Java creates many more objects. If you rely on that, your perfect Java written code may (may) become a powerful... resource eater.

PARTNERS