Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 27 Feb 2009
Online Last Active Today, 04:15 PM

#5169642 [SOLVED] What is a browser?

Posted by Ectara on Yesterday, 07:05 PM

Hardware acceleration removal would mean no OpenGL/DirectX is being used?

Yes, only as an after-thought for speed if enabled during build.


Usage of Javascript means that is another language used besides the core C++ , so that is the reason that you cannot agree to the subset of my statement "it's simply C++"?

"Usage of another language means that another language is used, so is that the reason that you cannot agree to my statement that only one language is used?"



Did you seriously skip the whole article, looking for the first link? The fact that it uses Cairo is irrelevant: it is what it does, not how.


Menus and similar "Control Graphical components" are usually implemented using other libraries, but can be implemented using one of (many?) rendering APIs like OpenGL and/or DirectX.

What if I told you that window toolkits like GTK+ don't need to and probably don't use OpenGL/Direct3D? 3D hardware rendering is unnecessary.

#5169626 [SOLVED] What is a browser?

Posted by Ectara on Yesterday, 05:36 PM

In the sense that it's simply made of C++ and OpenGL/DirectX,

You can compile Firefox with hardware acceleration support removed, voiding your claim.
Note that since a lot of the Firefox UI and preference engine uses JavaScript, this voids the claim that C++ is all that's used to write the program.

rendering( graphical interface components, images, fonts ,ect ect)

A lot of the font rendering and GUI is GTK+ in Linux. Look up windowing toolkits!

After having read the above, can you confirm that, or am I missing/misunderstanding something?

Please, please look up any of the terms in this thread in Google. It sounds like you decided that Firefox is just C++ and Direct3D/OpenGL, and you're going to repeat your question until we agree with you.

#5169583 [SOLVED] What is a browser?

Posted by Ectara on Yesterday, 02:02 PM

The case with a VM is additional for more unusual usage.

The application runs in a VM the same way it does on a normal physical computer. You have the option to turn off hardware acceleration right now, so it isn't unusual if you have a driver bug, or something.




BUT, on the VERY BASIC and CORE it's just C++/etc and OpenGL/DirectX.

That ignored everything I just said.




Do tell me otherwise if that is not the case though.

A cursory Google search will tell you what it is. It is (in this case) the process of rendering a 3D scene without using hardware acceleration, done completely in software. In other words, performing the tasks of OpenGL/Direct3D without the use of hardware acceleration. The Mesa library is a good example.


Edit: Also, the use of toolkits like GTK+ is of considerable importance.

#5169564 [SOLVED] What is a browser?

Posted by Ectara on Yesterday, 01:04 PM

I needed only a simple answer like "SimonForsman" pointed out, it uses C++ and OpenGL.

Firefox uses C++ GTK+ and OpenGL on Linux atleast

Not quite what he said, and it sounds like an oversimplification of his post.


Based on that I can confirm that browsers(internet, typical/graphical) are indeed simple applications utilising DirectX/OpenGL and C++(or other programming language(s)).

This isn't accurate. When I run Chrome in a VM, I have to disable hardware acceleration to keep it from drawing incoherently. Thus, without hardware acceleration, it is using a software renderer. That contradicts your conclusion that Direct X or OpenGL are in use at all times. Mozilla has long since had the ability to use DirectDraw or X Render, whether or not it's recommended in the presence of other, more efficient APIs. This is another contradiction of the idea that these Direct X and OpenGL are the only two APIs used.

#5169534 [SOLVED] What is a browser?

Posted by Ectara on Yesterday, 11:16 AM

Let me ask the remainder of the question, what rendering is used for Firefox? (thanks for the links, but I wouldn't spends hours or days looking at the source files just to be able to tell)

Also note that a lot of browsers support other acceleration, like DirectDraw, and have the capability to turn off hardware acceleration if it turns out to be buggy, doing everything in software. There may not be one answer for you.

#5162928 Help with the math on this?

Posted by Ectara on 25 June 2014 - 10:42 PM

If you are not interested?

No one said I wasn't interested. To be honest, I never thought of it that way.


it is NOT useless to fill in more information about a topic.

Never said that.


Of course, if Paradigm Shifter was attempting to build on fir's answer with more information for the sake of knowledge, then that's well and fine.

I have no idea where you are getting the idea that I am against his insight.

#5158643 Is working in terminal/console really a waste of time?

Posted by Ectara on 06 June 2014 - 02:47 AM

After tutoring several students in C++, Java, and x86 ASM, the thought of trying to have them learn GUI programming at the same time terrifies me. These beginners don't understand pointers, they're unsure of how a for loop works, and they think a bit shift is a geological term. I feel that it would take them twice as long to make even a simple "guess the number" or "tic-tac-toe" game if they're thrust into using a GUI immediately for these reasons (off of the top of my head):

  • They now must learn about memory management way early, before they can even get any output drawn (unless they lucked out with a language that has garbage collection).
  • They have to learn not just the core language, but also the API of a graphics library that makes use of more advanced features, and manage linking and dependencies.
  • They are force-fed inheritance lessons for many languages; if I want to watch for input, I have to add an event listener object, and have it inherit from a standard base class? What is "inherit", and what's a "base class"? I didn't even get much more than a "hello, world" yet.
  • Unless they plan to learn how fonts work to print text, there's going to be a lot of taken-for-granted boilerplate code and hidden default values being used. I've experienced that teaching people right away, "Do not pay attention to this. It is magic," only discourages them, thinking that they'll never understand it all, it has a mind of its own, and that they'll never actually need to know it. It's the kind of training that teaches them to start every source file with:
    #include <iostream>
    #include <string>
    #include <windows.h>
    #include <conio.h>
    #include <fstream>
    #include <iomanip>
    using namespace std;
    whether any of it is actually needed or not, because they had problems once and that made it go away, so they may as well put it everywhere.

If you aren't a beginner to programming, but only to game programming, I interpret this thread as not applying to you, as you should already know these basics.
Furthermore, to suggest that rather than teach people from the ground up with the terminal/console, or scare them with GUI programming and its requisite complexity, we give them a very high-level scripting language, that may not be beneficial. If they want sounds and pictures now, okay, fine. If they actually want an understanding of how things work, it won't be at all obvious (what's a hash table look-up, and why is my loop slowing to a crawl by not caching the property value?); low-level knowledge spots anti-patterns in high-level code. If you want to start someone on high-level scripting languages, plan on having them go back and learn a low-level language later before they actually start producing their life work, unless you're banking on them striking it rich with their Alice, Scratch, or DesignBlocks skills.


#5158636 Checking if a bit is set in a byte

Posted by Ectara on 06 June 2014 - 02:07 AM


I do it like this, but I'd have the enum in it's own header to be reused

enum struct BIT{
	_1 = 0x1,
	_2 = 0x2,
	_3 = 0x4,
	_4 = 0x8,
	_5 = 0x10,
	_6 = 0x20,
	_7 = 0x40,
	_8 = 0x80,

int eg = 20;

if(eg & BIT::_5){


That forces people to be one-indexed for bit enumeration; sometimes, being zero-indexed is easier, when you use that index directly as the number of positions to shift. Or, put another way, if the index is the exponent of 2 for the value represented by the bit at that index.

#5155163 A Rose by Any Other Name...

Posted by Ectara on 21 May 2014 - 08:39 PM

How about on case-sensitivity?

...That doesn't quite answer the question. As outlined, there are other languages (disregarding accents) that have different character sets that can be substituted for each other (barring grammatical convention). When we think "case-insensitive", we tend to think of common Germanic, Romance, Indo-European, etc. languages only. There's a potential for this behavior in other languages that we intentionally ignore. It seems rather strange to have this core kernel feature that is only effective for a portion of the languages spoken by the user base, and thus, I don't feel that it belongs in the kernel. It seems like an esoteric part of the time period where a subset of the English alphabet was all we cared about, with everyone else as an after-thought.


I think that's a different issue - isn't that just a matter of the filesystem not actually enforcing full case-insensitivity?

swiftcoder nailed this one precisely - I frequently dual-boot between Windows and Linux. I could mount my NTFS partition right now and create two files that differ in name only by case. It doesn't seem wise to pretend that this can't happen (though, I know it will forever stick around due to the compatibility issues of ever changing it).


My stance is that case-insensitive filesystems (for those language for which case is actually a relevant concept) are more convenient to the user than case-sensitive filesystems.

Though I'm a developer, I'm also a user: I find it a big pain. Nothing like trying to find something you've referred to, only to have trouble finding it because it wasn't named with the case that you've always that it had. I find case-sensitivity to be very brittle; any break in the case-sensitive seal, and all hell breaks loose. Often, as a user, I find that software doesn't do case insensitivity properly.


This reminds me of a bug in the product inventory software I had written at work. To make life easier on the people entering the data for product listings, you could enter a partial name, and it would show a drop-down list of possible matches based on a case-insensitive search. Well, it would search case-insensitively, and it would find it for display, but if you didn't click on it and have it fill out the correct name for you, and you didn't type in the correct case, it would pass the check to see if it is in the database (case-insensitively) after submitting, but it would choke when it accidentally looked up the ID of the product in a case-sensitive manner, resulting in several listing records having null product IDs, failing after the input was already validated.


My point to the story is that if you ever decide to uphold case-sensitivity, your workload is now doubled: if you slip up even once and do something in a case-sensitive manner, it may produce serious bugs that defy expectations, especially if it fails on the backend, after the input's already declared valid.


This is why I feel that case-insensitivity should be in the top-most layer, facing the user, and out of the core:

  1. It is only useful for part of the user base.
  2. Not all users enjoy the feature; many hate it, especially those that spend more time in other operating systems.
  3. It is very brittle.

#5154516 A Rose by Any Other Name...

Posted by Ectara on 18 May 2014 - 05:21 PM

That used to be (still is?) an issue with "portable" webservers, too. If someone named the page you were trying to read ThePage.htm, the webserver would show a 404 because you would of course try to get http://example.com/thepage.html (which would fail on two accounts, the capitalization and the extension). But hey, why do you have to do the dance for the darn computer? It's not like rocket science to figure out what you want if there is just one name with the same (except capitalisation) basename and an alternate spelling of the extension.

On one hand, users shouldn't be exposed to bare file path URLs, with modern URL rewriting and the majority of pages being accessed through links from other pages.




On the other hand, I don't care whether a file that I want to open is spelled foobar or FOOBAR or FooBaR, there exist no other files with alternative spellings, and I'm just interested in opening the darn thing, regardless of such sopistries whether "F" and "f" are binary identical or not. laugh.png

Whoops, forgot you were only talking about file names, sorry.


I've always felt that the case-insensitivity in file names was a relic of an outdated era (like using FAT32, with its case-insensitivity, but case remembrance), and was due to the constraints of the technology (and the convention that followed from its use), rather than conscious design decision on the OS' part. Case sensitivity also reduces the number of possible file names by a great factor.

Now, where do we draw the line on case-sensitivity? What about diacritics? Should an 'ñ' and an 'n' be considered the same letter in a case-insensitive file system? A lot of people make no distinction between case-sensitive and accent-sensitive. I wouldn't want to be the poor sap that was writing a Spanish application that looked for "año.jpg", and found "ano.jpg". How about Japanese? I found it useful to be in a Japanese book store, and look for a particular book by typing its name in katakana in the search terminal; I know how the title is read, but I can't write it in kanji. However, for file names, that's a poor solution (see an example of this, using romaji instead of katakana, here: http://www.cjk.org/cjk/reference/japhom.htm#2); there are many different words and phrases that wind up being homophones, so being able to type a file name in katakana or hiragana means that you'll hit serious ambiguity with several different file names of different meaning corresponding to the same phonetic sounds that can be expressed in katakana or hiragana. So, while this is suitable for, say, a book store search terminal to allow illiterate people like me to find literature, I find this to be a poor solution for a file system. There are many other languages to consider in this regard.


In short, our notion of file system case-insensitivity generally only apples to ASCII English characters, and, in my opinion, is a hold-over from when even that was more than we wanted to or could care about. It's a slippery slope, without considering the implications of anything that isn't English, leading to an inconsistent representation of file names. Furthermore, we already know it is possible to encounter "File.txt" and "file.txt" at the same time in a lot of filesystems; using a scheme that can't deterministically pick one or the other just asks to be bitten by this.

#5154278 A Rose by Any Other Name...

Posted by Ectara on 17 May 2014 - 09:40 AM

Assuming that case matters and that you can safely use "Print" and "print" seems to be a bigger WTF to me.  Most of the world has long since moved on from those days, and even in places where it still does matter (such as C) seeing this kind of thing would make me wince.

I prefer things case-sensitive. It allows greater semantic distinction at a glance. Most people looking can easily tell that "object" is likely a variable, "Object" is likely a composite data type, and "OBJECT" is likely a constant. If you don't have namespaces or other types of scoping where you can solve the problem with more typing, you'll have to take greater measures to ensure that you don't define two things with the same name that have a different purpose.




The sooner that the rest of the world wises up and ditches case-sensitivity the better. I long for the day when I'm writing or reading code and I no longer have to fret over whether it was really intended to use "E" or "e" (simplistic examples to illustrate a point) in the current block (particularly if they're the same type).

I never run into that problem. Constant? All upper, with underscores. Composite type? Title case. Function or variable? Camel case. Dealing with others' code is behind a layer, so that the differing styles are contained.


If someone did enforce case-insensitivity in my favorite languages, I'd keep writing with the style rules I do now, except I'd have to tag everything with something like Systems Hungarian notation to ensure that I never have, and never will, accidentally re-use the same identifier in the same scope for two very different purposes.

#5153798 A Rose by Any Other Name...

Posted by Ectara on 15 May 2014 - 10:38 AM

Writing assembly in this day and age might be the real WTF smile.png

It's for a class I have to take; I'd really rather not have to take it, but it's required.

#5153705 A Rose by Any Other Name...

Posted by Ectara on 14 May 2014 - 10:42 PM

I figure, it's my turn to try my hand at a coding horror. This one had me stumped for a couple better-spent-elsewhere hours:

	mov edx, OFFSET menu	; print menu of operations
	call WriteString
	call ReadChar
	call WriteChar
	call Crlf

	cmp al, 'p' ; If 'p' was entered...
	je print    ; ...print nodes


	mov edx, OFFSET error	; Print invalid option message
	call WriteString
	jmp menu_prompt

	push cur
	push head
	call Print

	jmp menu_prompt
	call WaitMsg	; hold display window open
main ENDP

Print PROC
Print ENDP

I was trying to figure out how the values of the cur and head pointers weren't being stored on the stack before the call to the Print procedure; the program repeatedly generated a memory access violation when it tried to dereference the pointer, and I'd be sitting there rooting around the stack frame, and the values are nowhere to be found, like they've never been pushed on the stack before the call. Huh. Visual inspection of the code provided no answers. If you see it already, you're better read than I am on this assembler.
The answer? (MASM transforms all identifiers to uppercase by default, for case-insensitivity! Thus, my jmp statement was just jumping to the Print procedure, without pushing its parameters on the stack, instead of jumping to the print label. I have no idea why the assembler wouldn't raise an error or a warning for that, but I've learned my lesson [just started using MASM, in particular, not long ago].)

#5151508 why in many fps games player character doesnt talk?

Posted by Ectara on 04 May 2014 - 06:46 PM

I would also add that a speaking FPS character could just confuse the player.

I definitely agree, though it does work in some places; Halo's voices in ODST and later were well done, in my opinion; each character (or voice set) had their own set of grunts or speech that would be spoken when they performed certain actions, such as scoring a headshot, reloading, or taking damage.


In Left 4 Dead, I think the speaking player worked out perfectly, and added more weight to the story. It's also essential for conveying information to others without a microphone, as your character shouts out what they're seeing, and signals when they're being attacked or incapacitated, etc.

#5151476 why in many fps games player character doesnt talk?

Posted by Ectara on 04 May 2014 - 03:21 PM

Even if it isn't to put the player in the character's shoes, sometimes the "strong, silent type" is a valid personality. I had a greater respect for Soap after COD4, as he epitomized the perfect soldier: completed impossible tasks, had the utmost respect for his superiors without doubt or hesitation, and had nothing to say. Put another way, from a superior's perspective, a perfect subordinate performs all tasks with the utmost efficiency, and does not let personality get in the way. Having a serious, if not mysterious, character can be something admirable for players that prefer it.